ElevenLabs published a guide to integrating its meeting transcription API on October 8, 2026, outlining two implementation approaches with Scribe v2 and Scribe v2 Realtime. For product development teams, the key is choosing between captions during a meeting and processing recordings afterward, rather than treating all note-taking needs as the same task.
According to ElevenLabs’ guide to its meeting transcription API, apps send audio to the service and receive text for note-taking, search and integration with internal workflows. This is an integration guide, not an announcement launching two new models.
Two processing paths for two different points of use
Scribe v2 Realtime is presented as an option for live audio streams. The app maintains a connection and receives results as participants speak. This approach suits in-meeting captions or assistants that need to receive content during the discussion itself.
Scribe v2 processes audio recordings in batches, meaning files are submitted for subsequent transcription. This approach is better suited to products that only need transcripts for storage, search or as input for generating post-meeting notes.
The important difference is when results are needed. If users need to read captions immediately, post-meeting processing cannot meet that need. Conversely, a product used only to look up recordings does not necessarily need to maintain a live transcription stream.
ElevenLabs says the models support more than 90 languages. However, the range of supported languages does not in itself demonstrate accuracy in individual meetings, especially when there is noise, specialized terminology or multiple speakers taking turns.
The 150 ms figure needs to be understood correctly
In the documentation, ElevenLabs cites 150 ms latency for Scribe v2 Realtime, referring to partial transcription results. This is a vendor-published specification, not an independent measurement of the full experience in a particular app.
A real-world system also has to capture audio, transmit data, receive responses and display text. The model’s specification therefore does not mean users will always see complete captions after exactly 150 ms.
Partial results also differ from a finalized transcript. The content on screen may need updating as the system receives more audio. For products that use text to trigger actions, this distinction directly affects when processing takes place.
For example, receiving a phrase from a meeting is not enough to determine that it represents a final decision. The speaker may revise their point or add a condition in the next sentence. The transcription layer provides data; interpretation and task execution belong to the application layer that follows.
The API is not a complete meeting assistant
The guide describes opening a WebSocket connection, sending audio and handling returned events. This shows that the API is one component of a product’s architecture, not the entire process of joining meetings, recording audio and producing minutes.
Development teams still need to address the audio source, access permissions, participant notifications and where results are stored. Speech-to-text capability alone does not establish that a system has a bot that automatically joins meetings on every platform.
This is also the boundary drawn in the article on employees building their own AI apps and the governance challenge: building a prototype does not mean having an application ready to operate with enterprise data.
ElevenLabs provides an example of creating a single-use token on the server so a client-side app can send audio without exposing the main API key. This setup separates service credentials from software running on users’ devices, but does not replace user authentication and permission controls within the product.
A transcript is a data source, not confirmed meeting minutes
ElevenLabs describes meeting transcription output with timestamps and speaker labels. These elements can help locate parts of a discussion, but labels that distinguish voices do not in themselves confirm each person’s real identity.
A transcript also differs from a summary. Transcription records speech; summarization selects and interprets content. If an app generates a to-do list, it needs to distinguish proposals, commitments and agreed decisions rather than turning every statement into a task.
When data is fed into an internal assistant, preserving its source and status becomes important. The article on managing context when AI works over extended periods further explains why systems need to retain decisions and data accurately across multiple work sessions.
Timestamps also have value beyond meeting notes. In a workflow for using AI to cut long videos into short clips, a transcript can help locate sections to review. Even so, selecting sections and checking their context remain separate steps.
Privacy and costs still depend on implementation
ElevenLabs says a Zero Retention mode is available for enterprise customers. This does not mean every account or every default configuration is subject to the same data retention conditions.
Even if the provider does not retain content under a particular mode, the app may still store audio, transcripts or logs in its own systems. Privacy assessments therefore need to cover the entire data flow, not just one API option.
The documentation also compares live and batch processing in terms of cost and accuracy. However, the guide is not sufficient to conclude that one approach is always cheaper or more accurate in every implementation. Results also depend on configuration, recording quality and product requirements.
The published information clarifies the two integration paths and how audio is transmitted. Factors such as total operating costs, quality in Vietnamese-language meetings and end-to-end latency still need to be evaluated using real-world data from each app.