Google Retires Meet’s Live Media API. The REST Alternative Has a Different Job.

Google is closing the Meet Media API, a developer preview that let applications receive live audio and video from a conference. The retirement notice published October 28 sets January 15, 2027 as the endpoint shutdown date and directs developers toward the supported Meet REST API for meeting workflows.

The accompanying notice in googleworkspace/meet-media-api-samples says the preview will not reach general availability. The recommended REST path preserves useful work, including summaries built from generated transcripts. It does not preserve every possible job. A service that needs to inspect the conversation’s media as it happens depends on a different input from a service that can wait for a file.

The preview had a real media connection

Google announced the Media API preview on February 24, 2025. Its public sample shows what that promise meant: a WebRTC connection requests receive-only audio and video tracks and hands arriving tracks to the application. This sits between the meeting and whatever software analyzes its media. It is not a model feature or a transcript-download button.

The sample’s connection handshake posts an offer to a v2beta method named connectActiveConference. That HTTP endpoint establishes the retiring media connection; its REST-shaped address is not evidence of a separate surviving media service. The receive-only sample also does not establish an agent that can speak back into the meeting.

The reversal is now in the repository. An October 28 README change says the API will not reach general availability. The sample repository is archived. This is an experimental route failing to graduate, not a generally available entitlement suddenly withdrawn from every meeting application. Existing approved preview participants retain transitional access until the announced shutdown.

“Something happened” is different from hearing it

The supported REST API can still work during a call. It exposes meeting information, participant sessions and controls such as ending an active conference. Calling it a post-meeting-only API would hide a substantial part of the available system.

The separate Workspace Events API supplies notifications when a conference starts, a participant joins or a transcript file is generated. Its documented payload identifies the changed resource. A notification that someone joined is useful for attendance or workflow coordination; it contains neither their spoken words nor their video frames.

The current v2 REST contract exposes meeting spaces, conference records, participant information and generated artifacts. We found no equivalent to the sample’s live media connection in that contract. This is the consequential gap in the suggested migration: knowing the meeting’s state and receiving its conversation are different capabilities.

A recording that ended may not be ready

The recording resource makes the content boundary precise. It distinguishes an active recording, an ended recording whose file is not yet available, and a generated file ready to download. The destination is an MP4 in Drive. An application must account for file readiness, rather than treating a recording-ended notification as downloadable media.

This is a recording-session distinction, not a claim that every artifact appears at one fixed delay after the entire meeting ends. Google’s artifact guide also requires generation to be configured before the conference finishes and appropriate access to retrieve the result. Transcription can run independently of video recording. A migration therefore needs to preserve the required source material, its permissions and the moment the application can use it.

For a summary or action-list service, that can be a workable design: wait for the relevant artifact, retrieve it with authorization, then analyze its contents. For a feature that must react to the actual audio or video during the conversation, substituting a finished file changes the product’s timing and purpose.

We inspected Google’s notices, pinned sample code and public API contracts; we did not connect to an authenticated meeting or measure artifact delays. These sources do not establish how many applications used the preview or what happens to bots built through other routes. The next useful evidence is a documented migration that preserves a specific assistant’s job—or a supported replacement for its live media input. Until then, the migration question is concrete: does the application need to know that something happened, read the resulting file, or hear it happening?