Question:
I am building a desktop application that creates Google Meet conferences and enables automatic transcription.
My exact requirement is:
Given only a Google Meet URL / meeting code, can I reliably and programmatically identify the corresponding Google Drive transcript file after more than 30 days have passed, when the Google Meet
conferenceRecordand transcript resources are no longer available through the Meet REST API?
Example lifecycle:
- My application creates a Google Meet meeting.
- I have the Meet URL, e.g.
https://meet.google.com/abc-defg-hij. - Before the meeting, I enable automatic transcription using the Meet API.
- The meeting takes place and a transcript is generated.
- Google saves the transcript in the organizer’s Google Drive.
- My desktop application may remain completely closed for 2+ months.
- When the application starts again, the Meet API
conferenceRecordmay already have expired. - At that point I want to use only Google Drive API to locate the transcript corresponding to the original Meet URL.
I understand that Google documents a 30-day lifetime for conferenceRecords and transcript entries. However, I also understand that the transcript Google Doc is a separate Drive artifact and may remain in Drive according to Drive retention policies.
========== What I need to know ===========
A. Is there a permanent/documented identifier relationship between a Meet meeting and its Drive artifacts?
For example, is there any guaranteed relationship such as:
Meet URL
↓
meeting code / space name
↓
Drive meeting folder
↓
transcript Google Doc
Specifically, does the Drive meeting folder or transcript file contain any documented metadata referencing:
- the Meet
space(spaces/...) - the Meet URL
- the meeting code (
abc-defg-hij) - the Calendar event ID
- the conference ID
- the original conference/meeting identifier
that remains available after the Meet conferenceRecord expires?
B. Regarding the new Google Drive organization for Meet artifacts
Google now places Meet artifacts in a Google Meet folder and meeting-specific subfolders.
Is it officially guaranteed that the meeting-specific folder can be correlated to the original meeting by its name?
For example, if I create a Calendar event with:
[MYAPP:01JXYZ123] Customer Meeting
and that event creates the Meet:
https://meet.google.com/abc-defg-hij
is Google guaranteed to create something equivalent to:
My Drive/
└── Google Meet/
└── [MYAPP:01JXYZ123] Customer Meeting/
└── ... transcript ...
Or is the folder naming purely implementation/UI behavior and therefore not safe to rely on programmatically?
C. Can I use Drive API alone after 30+ days?
Suppose the application was completely offline when the transcript was generated and therefore never obtained:
conferenceRecords/.../transcripts/...
docsDestination.document
Two months later, can I use drive.files.list() to deterministically find the transcript from the original Meet URL?
If yes, what exact Drive API query/fields should be used?
For example, can I reliably use some combination of:
parents
name
mimeType
createdTime
modifiedTime
appProperties
properties
to establish the relationship?
D. Can metadata be injected before the meeting?
Is there any supported way, when creating or patching a Meet space / Calendar event, to tell Google:
myMeetingId = "01JXYZ123"
and have that identifier automatically propagated to the future Drive transcript/recording/meeting folder?
For example, can a Meet space, Calendar event, or Meet artifact configuration contain arbitrary metadata that later appears as Drive appProperties or properties?
If not, is putting a unique application ID into the Calendar event title/Meet name the only supported way to create a correlation that can later be discovered through Drive API alone?
Most important question
I am specifically looking for a documented, API-supported, future-proof correlation, not a behavior observed in the Google Drive UI.
If Google does not provide a permanent Meet-URL → Drive-file identifier mapping after conferenceRecord expiration, please state that explicitly.
In that case, what is the officially recommended architecture for an application that may be offline for months and must later recover the Meet transcript from Drive without relying on the Meet REST API?
I would especially appreciate links to the exact Google documentation that guarantees each part of the proposed solution.
Thanks in advance!