--- name: google-meet-oauth-app description: >- The Google Meet layer on top of the shared `google-cloud-console-oauth` skill — the sensitivity tier of every Meet scope (`meetings.space.created` and `meetings.space.readonly` sensitive, `meetings.space.settings` non-sensitive, Meet Media API scopes restricted), the three things people call "Meet support", the Meet REST API surface, why recordings and transcripts are Drive files and so restricted-tier, the Workspace editions required, event subscriptions, and quotas. Use when asked to get Google Meet OAuth credentials, register or scope a Meet app, choose between the `meetings.space.*` scopes, judge whether pulling recordings or transcripts forces a CASA assessment, or explain why a Meet connection returns no conferences. Read `google-cloud-console-oauth` first for the console mechanics, `google-calendar-oauth-app` for Meet links on events, and `google-drive-oauth-app` for downloading artifact files. --- # Google Meet OAuth2 App Registration Meet is the Google product where the scope tier depends entirely on *which* of three unrelated capabilities someone means. A Meet **link** on a calendar event costs nothing beyond the Calendar scope already in hand. Meet **space and conference metadata** costs one sensitive scope. **Recordings and transcripts as files** are read out of Drive, so they cost a restricted Drive scope, verification *plus* an annual CASA security assessment. All three get written on a ticket as "add Meet support." This file settles the tiers with the source for each, maps the REST API surface onto the scope that reaches it, and records the constraints that make a correctly-scoped Meet integration return nothing anyway — the organizer-only conference list, the Workspace editions without which no artifact is ever produced, and the admin switches on top. Everything else is shared. ## Built on: `google-cloud-console-oauth` **Read `google-cloud-console-oauth` first, then this file.** It owns all the console mechanics, and this file does not repeat them: - Choosing/creating the Cloud project and organization, enabling APIs, and who may administer it. - Configuring the app on the Google Auth Platform (Branding, Audience, Data Access, Clients) and creating a **Web application** client — the only type that yields a usable client secret. - Redirect-URI rules (exact matching, HTTPS-only, propagation delay) and the platform's per-data-center callback list. - The generic scope model: declaring every scope on Data Access, the non-sensitive / sensitive / restricted tiers, the rule that the app's tier is its most sensitive scope, and `access_type=offline` + `prompt=consent` as the only way to get a refresh token back. - The client secret being shown and downloadable **only once at creation**, add-then-disable rotation, `Testing` vs `In production` and the seven-day refresh-token expiry, the unverified-app screen, the 100-user caps, verification, the annual CASA assessment at assurance level AL1/AL2, and the Workspace admin API controls in their generic form. If you are reading only this file, you are missing all of the above. ## Inputs to collect before you start The base skill lists the console inputs. These are the Meet-specific ones, and the first three decide the cost: | Input | Notes | | --- | --- | | **Link, metadata, or the files?** | The three tiers in §2. Ask before anything else — the answer decides whether a security assessment is in scope | | **Only spaces this app creates, or any meeting the user can reach?** | `meetings.space.created` vs `meetings.space.readonly` — and Calendar-created meetings are *other apps'* spaces (§3) | | **Does the app need to change meeting settings (auto-record, auto-transcribe, moderation)?** | `meetings.space.settings`, which is non-sensitive (§1) | | **Real-time audio/video, or after-the-fact artifacts?** | Real-time means the Meet Media API: restricted scopes **and** a Developer Preview enrolment (§5) | | **What Workspace edition do the customers have?** | No edition, no recording or transcript — the API is not the gate (§4) | | **Whose Drive holds the artifacts?** | The meeting organizer's, not the authorizing user's (§4) | | **Push events or polling?** | Workspace Events subscriptions need Pub/Sub and expire in days (§7) | ## Quick Start 1. Work the base skill's console steps, and **enable the Google Meet REST API** on the project — plus Drive, Calendar or Workspace Events if §6 says so. 2. Settle which of the three capabilities in §2 is actually wanted, in writing, before touching Data Access. 3. Pick scopes from §1 and check the tier against the Meet auth guide's own table, not from memory. 4. If recordings or transcripts as *files* are in scope, stop and read `google-drive-oauth-app`: that is a restricted Drive scope, a permitted-application-type gate and an annual assessment (§4). 5. Confirm the customer's Workspace edition actually produces the artifact at all (§4) before promising it. 6. Declare exactly those scopes, request exactly those scopes, and finish the base skill's capture, round-trip and handoff steps with the Meet checks in §9. ## Meet platform state (verified 2026-09-20 — re-verify before trusting) - **Google publishes a per-scope tier table for Meet**, on the Meet REST API authenticate-and-authorize guide (page last updated 2026-09-14). It is the authoritative statement and it is unambiguous — see §1. - **The Meet REST API is v2**, at `https://meet.googleapis.com/v2`, with a `v2beta` carrying preview features. - **Meet scopes do not appear on the Cloud console's restricted-scopes list**, which covers Gmail, Drive, Fit, Data Portability, Photos Ambient and Health. Meet's only restricted exposure is via Drive scopes (§4) and via the Meet Media API scopes, which Google's Media API page calls restricted although that list does not enumerate them (§5). - **The Meet Media API is Developer Preview only.** The Cloud project, the OAuth principal *and every participant* in the conference must be enrolled in the Google Workspace Developer Preview Program (§5). - **Meet REST API usage is free today, with a stated intent to charge.** Google's usage-limits page says exceeding the quota limits "is planned to incur charges to your Google Cloud billing account later in 2026" (§8). - **Artifacts moved folders in July 2026.** Meet now writes transcripts into a "Google Meet" folder with a per-meeting sub-folder; the old "Meet Recordings" folder was renamed "Legacy Meet Recordings" and moved inside it. Anything matching on folder name will have broken (§4). - **From 30 April 2026, viewers and commenters on new Meet recordings can copy and download them** unless an admin changed the setting before that date. A customer's assumption that recordings cannot leave the org may be stale. If the Meet scope table or the Media API preview gate does not look like this, stop and report what you actually see. ## 1. The Meet scope tiers — the answer Every scope below is a `https://www.googleapis.com/auth/` URL; the table drops the prefix for width. | Scope | Grants (Google's wording) | **Tier** | Source | | --- | --- | --- | --- | | `meetings.space.settings` | "Edit and see the settings for all of your Google Meet calls." | **Non-sensitive** | Meet REST API auth guide | | `meetings.space.created` | "Allow apps to create, modify, and read metadata about meeting spaces created by your app." | **Sensitive** | Meet REST API auth guide; repeated on the Workspace Events API scopes page | | `meetings.space.readonly` | "Allow apps to read metadata about any meeting space the user has access to." | **Sensitive** | Meet REST API auth guide; repeated on the Workspace Events API scopes page | | `meetings.conference.media.readonly` | "Capture real-time video and audio in Google Meet video calls." | **Restricted** | Meet Media API get-started guide | | `meetings.conference.media.audio.readonly` | "Capture real-time audio in Google Meet video calls." | **Restricted** | Meet Media API get-started guide | | `meetings.conference.media.video.readonly` | "Capture real-time video in Google Meet video calls." | **Restricted** | Meet Media API get-started guide | | `drive.readonly` | "Allow apps to download recording and transcript files from Google Drive API." | **Restricted** | Meet REST API auth guide *and* the Cloud restricted-scopes list | | `drive.meet.readonly` | "View Drive files created or edited by Google Meet." | **Restricted** | Meet REST API auth guide *and* the Cloud restricted-scopes list | Read that table as three facts: - **No Meet REST API scope is restricted.** Spaces, conferences, participants, and the *metadata* of recordings and transcripts are all reachable at sensitive tier or below — verification with a justification and a demo video, but **no CASA assessment and no annual recertification**. `meetings.space.settings` is cheaper still: non-sensitive, basic app verification only. That is unusual, and it is worth saying out loud to anyone budgeting the work. - **Every Meet Media API scope is restricted.** Google states it plainly: "Due to the sensitive nature of conferences, all Meet Media API scopes are restricted." - **The restricted cost enters through Drive, not through Meet.** The moment the requirement is the recording or transcript *file*, the app needs `drive.readonly` or `drive.meet.readonly`, and the whole project moves to restricted tier (base §5: the tier of the app is the tier of its most sensitive scope). **What Google does not publish, and what to do about it.** Three gaps worth naming rather than guessing past: - The general **OAuth 2.0 Scopes for Google APIs** catalogue lists exactly three Meet scopes — `meetings.space.created`, `meetings.space.readonly`, `meetings.space.settings` — and assigns **no tier to any scope of any API**. It is a directory, not a tier source. Do not cite it for sensitivity. - The Cloud console's **restricted-scopes list does not mention Meet at all**, including the Media API scopes that the Media API page calls restricted. The two Google surfaces are not in contradiction — the list enumerates the classic restricted families — but if someone checks only the list, they will conclude Media API scopes are unrestricted. They are not: take the tier from the Meet Media API page and expect restricted-scope verification. - The Media API get-started page names a companion scope as **`meetings.space.read`** (Sensitive), a string that appears nowhere else in Google's Meet documentation and is not in the scopes catalogue, while the Meet REST API auth guide's equivalent is `meetings.space.readonly`. Treat `meetings.space.readonly` as the real string, **verify the exact spelling in the console's Data Access picker before declaring it**, and record what the picker says. An undeclared or misspelled scope drops users on the unverified-app screen (base §5). Where a per-scope tier is genuinely absent from Google's pages, say so and read the label off the Data Access picker — do not infer a tier from a neighbouring scope. ## 2. The three things people call "Meet support" | What is actually wanted | What it needs | Tier | Whose skill | | --- | --- | --- | --- | | A **Meet link** on a calendar event (create or read) | The Calendar event scope alone — no Meet scope, no Meet API | Sensitive (Calendar only) | `google-calendar-oauth-app` | | **Space / conference metadata**: meeting codes, settings, conference records, participants, artifact *metadata* | `meetings.space.created` or `meetings.space.readonly`; `meetings.space.settings` to write settings | Sensitive (non-sensitive for settings alone) | This file | | **Recording / transcript / smart-note files**: downloading or reading contents | A restricted **Drive** scope on top of the Meet scope | **Restricted** — verification + annual CASA | `google-drive-oauth-app` | | **Real-time audio/video** off a live call | Meet Media API scopes + `meetings.space.readonly` + Developer Preview enrolment | **Restricted**, and gated by preview access | §5 | The jump from row two to row three is the expensive one and it is invisible in the requirement's wording: "sync the meeting transcript" sounds like row two and is row three. The Meet REST API will hand out a transcript's *resource*, its state and its Drive export URI at sensitive tier; turning that URI into text is a Drive read. The jump from row one to row two is the cheap one people over-pay for: if the product only needs to put a Meet link on an event, or read the link off one, it needs no Meet scope at all and no Meet API enabled. ## 3. The Meet REST API surface, and which scope reaches what ``` spaces create / get / patch / endActiveConference conferenceRecords get / list (one per call inside a space) conferenceRecords.recordings get / list (MP4 in the organizer's Drive) conferenceRecords.transcripts get / list (Google Docs file) conferenceRecords.transcripts.entries get / list (speaker, timestamp, text, language) conferenceRecords.participants get / list conferenceRecords.participants.participantSessions get / list ``` Plus `spaces.members` for co-host management, and a smart-notes artifact resource alongside recordings and transcripts. `SpaceConfig` on a space carries access type, entry-point access, moderation and moderation restrictions, attendance-report generation, and the auto-artifact configuration for recording, transcription and smart notes. Four access rules decide whether a correctly-scoped call returns anything: - **`meetings.space.created` only reaches spaces this app created.** A meeting scheduled in Google Calendar is a space created by *Calendar*, not by your app. Google's own use-case table is explicit: reading artifacts or settings for conferences created by other apps needs `meetings.space.readonly` (and `meetings.space.settings` to read or edit the settings of any space the user can access through any other app). An integration that syncs customers' real meetings and requests only `meetings.space.created` will authorize cleanly and find nothing. - **`conferenceRecords.list` only returns conferences where the authorizing user is the meeting organizer.** Not attended — organized. "The app can only see meetings this person ran" is the documented behaviour, not a bug, and no scope widens it. Filterable fields are `space.meeting_code`, `space.name`, `start_time` and `end_time`; page size defaults to 25 and caps at 100. - **Artifacts are retrievable by a meeting space owner or participant**, and artifact objects only become useful once their state reads `FILE_GENERATED` — after the conference ends, with a lag. Poll the artifact endpoint, or subscribe to the file-generated events (§7). A conference that has ended is not a conference whose recording exists yet. - **Transcript entries are deleted 30 days after the conference ends**, and participant data is likewise documented as available for up to 30 days. Anything that needs the words later must copy them out inside the window — which, for the full text, means the Drive path and its restricted scope. Participants come back as one of `signedinUser`, `anonymousUser` or `phoneUser`. All three carry a display name; only `signedinUser` carries a user ID (interoperable with the Admin SDK and People API). Any identity mapping that assumes an email or an ID for every participant breaks on the first dial-in or unauthenticated guest. One policy line to keep in the handoff, because it is Google's own framing: the Meet REST API "isn't intended for performance tracking or user evaluation within your domain." ## 4. Recordings and transcripts: Drive files, and the editions behind them Meet saves recordings (MP4), transcripts (Docs) and smart notes (Docs) to the **meeting organizer's** Google Drive — not the authorizing user's. The recordings resource exposes a Drive destination with an `exportUri` for playback or download and a file identifier that corresponds to the Drive file. By default the artifacts are retained under normal Drive rules; an admin can manage them separately with Meet-specific retention rules in Google Vault. So the download path is a Drive read, with the restricted Drive scope from §1 and everything the `google-drive-oauth-app` skill says about restricted Drive scopes: verification, the permitted-application-type gate, and an annual CASA assessment. Google documents `drive.readonly` and `drive.meet.readonly` as the artifact-download scopes for Meet; it does not document a `drive.file`-based path for these files, so do not assume one exists. **Before any of that, the artifact has to exist.** Google publishes edition requirements per feature, and they differ per feature and even between Google's own pages: - **Recording** — the user-facing page lists Business Standard, Business Plus, Essentials, Enterprise Essentials, Enterprise Starter, Enterprise Standard, Enterprise Plus, Education Plus (Staff licence), Teaching and Learning Upgrade, Workspace Individual, and Google One subscribers with 2 TB or more. The admin-facing page's supported list is shorter (Business Standard and Business Plus; Enterprise Standard and Enterprise Plus; Education Plus; Essentials, Enterprise Essentials and Enterprise Essentials Plus). - **Transcripts** — Business Standard, Business Plus, Enterprise Starter, Enterprise Standard, Enterprise Plus, Teaching and Learning Upgrade, Education Plus, Workspace Individual. The admin page for turning transcription on or off lists a narrower set again (Business Standard; Business Plus; Enterprise Standard and Enterprise Plus; Education Plus). Transcripts are on by default except for Education student licences, run independently of recording, and are limited to eight languages. - **Smart notes ("take notes for me")** — "an eligible Google Workspace edition or Google AI plan", i.e. a Gemini entitlement, and only for work/school accounts or an eligible AI plan. Because those two Google lists disagree, **check the specific customer's edition rather than quoting a list**, and say in the handoff which page the answer came from. Three further ways an artifact fails to appear with a perfect token: - **Drive must be on for the organization and have free space** — in both the organization and the recording user's Drive. Drive off, or full, means no recording at all. - **An admin can require explicit in-meeting consent** from all participants before recording, transcription or smart notes start, and host-management settings decide who may start them. - **Auto-generation is per space and needs `meetings.space.settings`.** Pre-configuring auto-recording, auto-transcription or smart notes on a space — including a space Calendar created — is a settings write, and only meeting organizers, not co-hosts, can do it. ## 5. The Meet Media API: restricted, and preview-gated If the requirement is real-time audio or video off a live conference rather than a file afterwards, it is the Meet Media API, and the registration story changes: - **All three Media API scopes are restricted** (§1), so verification plus a CASA assessment, annually. - **It is Developer Preview.** The Cloud project, the OAuth principal and **every participant** in the conference must be enrolled in the Google Workspace Developer Preview Program. One unenrolled participant is enough to make a conference ineligible. - **The app must also request the general read-meeting scope** to read metadata and negotiate the connection — `meetings.space.readonly` per the REST API guide, spelled `meetings.space.read` on the Media API page (§1). - **A Workspace admin switch controls it**, off unless enabled: *Admin console → Apps → Google Workspace → Google Meet → Meet safety settings → Media API*, where the admin also chooses whether anyone from the host's organization may consent or only the host and co-hosts. Changes can take up to 24 hours. Participants are told when the Media API is in use and can turn it off mid-call. - **Consent, not just scopes.** A connection is only permitted when someone in the call can consent on behalf of the meeting; for a consumer-account (gmail.com) organizer the initiator must be present. Encrypted or watermarked meetings reject it outright, as do accounts registered to minors, and third-party hardware clients running Meet are unsupported. - Technical requirements are real engineering commitments — AV1, VP9 and VP8 with named decoder implementations, specific WebRTC header extensions, periodic client metrics, ~4 Mbps minimum bandwidth, 12 months' notice on codec changes. If someone reaches for the Media API because the REST API's post-meeting artifacts feel slow, push back: the REST API is the documented answer when real-time media is not genuinely required, and Google says so on its own page. ## 6. Which APIs to enable Enable on the Cloud project, before the first call: - **Google Meet REST API** — for everything in §3. Without it, authorization succeeds and the first call returns `403` with `accessNotConfigured` (base §8). It is also the API to enable for the Meet Media API. - **Google Drive API** — only if the app downloads or reads recording, transcript or smart-note files (§4). - **Google Calendar API** — only if the app also creates or reads events carrying Meet links (§2, and the Calendar skill). - **Google Workspace Events API** and **Cloud Pub/Sub** — only for push subscriptions (§7). - **Admin SDK** — only if the integration enumerates users org-wide. ## 7. Events and subscriptions Meet delivers push events through the **Google Workspace Events API** into a **Cloud Pub/Sub** topic; there is no direct webhook. Event types cover a conference started/ended, a participant joined/left, and recording, transcript and smart-note started/ended/fileGenerated. Target either a meeting space, or a *user* (which yields events for every space that user owns). The constraints that bite: - **Grant the Meet push service account `Pub/Sub Publisher` on the topic** — `meet-api-event-push@system.gserviceaccount.com`. A subscription that never delivers is usually this. - **Subscriptions expire fast.** Up to **7 days** when the payload excludes resource data, and up to **4 hours** — 24 hours with domain-wide delegation — when it includes it. Nothing auto-renews; renew or reactivate. Note also that Google documents including resource data as supported only for Chat resources, so plan on name-only payloads for Meet and a follow-up REST read. - **Subscription scopes are the Meet scopes, not a subscription-specific scope**: the Events API accepts `meetings.space.created` and `meetings.space.readonly` for Meet event types, both sensitive. - **Invitees are not the organizer.** Calendar invitees and other participants can receive only `google.workspace.meet.conference.v2.started` and `google.workspace.meet.transcript.v2.fileGenerated`. - Polling the REST API is the documented fallback for an outage or an inactive subscription — build it, given the 30-day windows in §3. ## 8. Quotas, and the coming bill Per-minute, per project and per user per project, from Google's usage-limits page: | | Per minute per project | Per minute per user per project | | --- | --- | --- | | Read requests | 6,000 | 600 | | Write requests | 1,000 | 100 | | Reduced write (space creation) | 100 | 10 | - Exceeding a quota returns **`429`**. Back off with truncated exponential backoff plus jitter — `min(((2^n) + random_milliseconds), maximum_backoff)`, random part under 1,000 ms, ceiling 32–64 seconds. This is not an authorization failure; re-authorizing a throttled connection burns a consent and fixes nothing. - **Within the per-minute limits there is no daily cap.** - **Space creation is the scarce one**: 10 per user per minute. A bulk provisioning job hits that first. - **Pricing.** Standard use is free today, and Google states that exceeding the quota limits is planned to incur charges to the Cloud billing account later in 2026. Anyone sizing a high-volume Meet integration should know that before launch, not after. - Quota increases are requested from the Cloud console's Quotas page; approval is not guaranteed, and a service account counts as a single account. ## Product fact — what the Meet connector asks for > **As of 2026-09-20, Unified.to's Google Meet connector requests**, per object and operation: > > - **Calendars, read:** `openid`, `profile`, `email`, `https://www.googleapis.com/auth/calendar.readonly` > - **Calendars, write:** `openid`, `profile`, `email`, `https://www.googleapis.com/auth/calendar` > - **Events, read:** `openid`, `profile`, `email`, `https://www.googleapis.com/auth/calendar.events.readonly` > - **Events, write:** `openid`, `profile`, `email`, `https://www.googleapis.com/auth/calendar.events` > - **Availability (busy), read:** `openid`, `profile`, `email`, `https://www.googleapis.com/auth/calendar.freebusy`, > `https://www.googleapis.com/auth/calendar.events.freebusy` > - **Recordings, read:** `https://www.googleapis.com/auth/meetings.space.readonly` — and **only** that; no identity > scopes accompany it, and there is no write configuration for recordings at all > - **Login/identity only:** `openid`, `profile`, `email` > > **Where that lands: sensitive at worst, never restricted.** `meetings.space.readonly` is sensitive (§1) and every > Calendar scope is sensitive; no Drive scope and no Media API scope is requested. So this configuration needs brand > and scope verification, and **no CASA security assessment** — the single most useful thing to tell whoever is > budgeting it. > > The consequence of that cheapness is the ceiling. Asking only for `meetings.space.readonly` means Meet **metadata**: > conference records and artifact resources, not the recording or transcript *contents*, which would need the > restricted Drive scope in §4. It also means the connector cannot create or configure spaces — no > `meetings.space.created`, no `meetings.space.settings` — so auto-recording and auto-transcription cannot be turned > on through it (§4), and the organizer-only rule in §3 still applies to whatever it does list. > > Auth quirks worth knowing: it is a Meet-branded connector whose main surface is Calendar, categorized for calendar > and identity, and pointed at the Meet v2 API host; it uses the standard Google authorize and token endpoints, asks > for offline access and forces the consent prompt (so a refresh token comes back on re-authorization, base §5), and > exchanges and refreshes by form POST with the client credentials. Alongside user OAuth it offers a **Google > service-account credential** path — domain-wide delegation — whose generated token is scoped to **full read-write > Calendar plus `meetings.space.readonly`**, which is broader than the read-only user configurations and is a > conversation to have with a customer's admin before enabling it. > > Because the recordings configuration is the one that pairs no identity scope with a single Meet scope, and every > other configuration pairs identity scopes with Calendar scopes, expect the **granular consent screen** in both > shapes (base §5): read the granted `scope` back from the token response rather than assuming (§9). > > Scope sets change. This note is dated, not live; confirm with the connector's owner before submitting anything. ## 9. Meet-specific end-to-end checks On top of the base skill's authorize → refresh round trip: 1. Make one real Meet read and confirm the Google Meet REST API is enabled and returning data. 2. **Compare the granted `scope` in the token response against what was requested.** A user who unticks the Meet scope on the granular consent screen produces a token that authenticates perfectly and 403s on every Meet call. 3. Test with a meeting the user **organized** and a meeting they merely **attended**, and confirm you understand why only the first appears in `conferenceRecords.list` (§3) before anyone reports it as a bug. 4. Test against a meeting created **from Google Calendar**, not one the app created — that is the case `meetings.space.created` cannot see (§3). 5. If artifacts matter, run the full lifecycle on an account whose edition actually supports them (§4): record or transcribe, wait for the artifact state to reach `FILE_GENERATED`, and confirm what the app gets is metadata plus a Drive URI, not content, unless a Drive scope was granted. 6. If events matter, create a subscription, receive one event, and confirm the app renews before expiry (§7). 7. Confirm participant handling for a dial-in or unauthenticated guest — no user ID comes back (§3). | Symptom | Cause | | --- | --- | | Auth succeeds, every Meet call `403 accessNotConfigured` | Google Meet REST API not enabled on the project (§6) | | Auth succeeds, Meet calls 403 but identity works | User declined the Meet scope on the granular consent screen (§9.2) | | Conference list is empty for a busy user | `conferenceRecords.list` returns only meetings that user **organized** (§3) | | Calendar-scheduled meetings are invisible | App holds `meetings.space.created`; Calendar created those spaces (§3) | | Recording or transcript resource never appears | Conference ended but artifact state is not `FILE_GENERATED` yet — poll or subscribe (§3) | | Artifacts never appear at all, for any meeting | Edition does not include the feature, Drive is off or full, or consent/host settings blocked it (§4) | | Transcript text is gone after a month | Transcript entries are deleted 30 days after the conference (§3) | | Artifact metadata reads fine, downloads fail | Downloading is a Drive read and needs a restricted Drive scope (§4) | | Some participants have no user ID | `anonymousUser` / `phoneUser` — only `signedinUser` carries one (§3) | | Event subscription goes quiet after days or hours | Subscription expired — 7 days name-only, 4 hours with resource data (§7) | | Subscription created but nothing ever arrives | Meet push service account lacks Pub/Sub Publisher on the topic (§7) | | `429` under load | Quota, not authorization — back off; space creation caps at 10/user/minute (§8) | | Media API connection refused mid-call or at join | Admin switch off, consent withheld, an unenrolled participant, encryption/watermark, or a minor's account (§5) | | Folder-matching automation stopped finding files | July 2026 artifact folder rename (Platform state) | ## Stop and ask Beyond the base skill's list, hand back to a human when: - The requirement is recordings or transcripts **as content**. That is a restricted Drive scope, the permitted- application-type gate and a funded annual CASA assessment — a product decision, not a console setting (§4). - Anyone wants the **Meet Media API**: restricted scopes plus Developer Preview enrolment for the project, the principal and every participant, plus a customer admin switch (§5). - A customer's Workspace **edition** does not include recording, transcripts or smart notes, and someone proposes shipping the feature anyway (§4). - The two Google edition lists disagree for the customer's exact edition and a commitment depends on which is right (§4). - The console's Data Access picker labels a Meet scope differently from §1, or shows `meetings.space.read` as a real scope — record what it says and report the discrepancy rather than declaring a scope on trust (§1). - Scopes would be narrowed or widened on a live integration — every customer re-consents. - Domain-wide delegation is proposed to get around organizer-only visibility (§3). It needs a customer super administrator and changes the trust model; it is not a fix for a scope that returns nothing. - Volume planning depends on the **future Meet API pricing** (§8). Get that from Google, not from an estimate. ## References Meet-specific only; the base skill carries the generic Google OAuth references, the Cloud restricted-scopes list and the OAuth scopes catalogue. Verified to resolve on 2026-09-20. - Authenticate and authorize Meet REST API requests (**the scope tier table**) — https://developers.google.com/workspace/meet/api/guides/authenticate-authorize - Meet REST API overview (resources, terms, artifact definitions, 30-day entries) — https://developers.google.com/workspace/meet/api/guides/overview - Meeting spaces overview (**OAuth scopes by use case**, space lifecycle) — https://developers.google.com/workspace/meet/api/guides/meeting-spaces-overview - Configure meeting space settings (moderation, auto artifacts, `meetings.space.settings`) — https://developers.google.com/workspace/meet/api/guides/meeting-spaces-configuration - Manage meeting spaces — https://developers.google.com/workspace/meet/api/guides/manage-meeting-spaces - Manage meeting space members (co-hosts) — https://developers.google.com/workspace/meet/api/guides/meeting-space-members - Work with conferences (organizer-only list, filters) — https://developers.google.com/workspace/meet/api/guides/conferences - Work with participants (signed-in / anonymous / phone users) — https://developers.google.com/workspace/meet/api/guides/participants - Work with artifacts (Drive destination, `exportUri`, retention) — https://developers.google.com/workspace/meet/api/guides/artifacts - Usage limits, backoff and the planned 2026 charging — https://developers.google.com/workspace/meet/api/guides/limits - Respond to events from Meet — https://developers.google.com/workspace/meet/api/guides/events-overview - `spaces` REST reference (SpaceConfig, ArtifactConfig) — https://developers.google.com/workspace/meet/api/reference/rest/v2/spaces - `conferenceRecords.recordings` reference — https://developers.google.com/workspace/meet/api/reference/rest/v2/conferenceRecords.recordings - `conferenceRecords.transcripts` reference — https://developers.google.com/workspace/meet/api/reference/rest/v2/conferenceRecords.transcripts - Meet release notes — https://developers.google.com/workspace/meet/release-notes - Meet Media API overview (preview gate, consent, eligibility) — https://developers.google.com/workspace/meet/media-api/guides/overview - Meet Media API get started (**all Media API scopes are restricted**, codecs, end-user requirements) — https://developers.google.com/workspace/meet/media-api/guides/get-started - Subscribe to Google Meet events (event types, target resources, invitee limits) — https://developers.google.com/workspace/events/guides/events-meet - Choose Google Workspace Events API scopes (Meet scope tiers, second source) — https://developers.google.com/workspace/events/guides/auth - Google Workspace Events API overview (subscription expiration: 7 days / 4 hours) — https://developers.google.com/workspace/events/guides - Create a Google Workspace subscription (Pub/Sub topic, Meet push service account) — https://developers.google.com/workspace/events/guides/create-subscription - Record a video meeting (editions that support recording) — https://support.google.com/meet/answer/9308681?hl=en - Use Transcripts with Google Meet (editions, folder rename, languages) — https://support.google.com/meet/answer/12849897?hl=en - "Take notes for me" in Google Meet (Gemini entitlement) — https://support.google.com/meet/answer/14754931?hl=en - Turn Meet recording on or off for your organization (admin editions, Drive prerequisites, April 2026 change) — https://support.google.com/a/answer/7557052?hl=en - Turn meeting transcription on or off (admin editions) — https://support.google.com/a/answer/12076932?hl=en - Control Media API access in Google Meet (admin switch, consent options) — https://support.google.com/a/answer/16333500?hl=en - Retain Google Meet data with Vault — https://support.google.com/vault/answer/7682297?hl=en