The first Zoom integration usually goes smoothly: webhooks fire, a VTT file lands, transcripts appear. The problems surface in production. Post-meeting latency measured in hours rather than seconds, accuracy degradation on accented or non-English speech, and no structured metadata for the downstream systems that actually need the data.
Transcription is not a side feature. Every CRM entry, coaching score, meeting summary, and action item extraction runs on the words the speech layer captured. When the first layer fails, every system downstream fails with it, often silently. This guide covers both architectural paths, the code to execute them, and the points where routing audio to dedicated speech infrastructure protects everything built on top.
Selecting your Zoom transcription strategy
The decision between batch and real-time splits on a single constraint: whether your product needs transcript data during the meeting or after it.
Streaming vs. batch API architectures
- Batch (REST pull): After a meeting ends, Zoom processes the Cloud Recording and fires a webhook. Your service downloads the VTT or audio file and runs enrichment. Total end-to-end latency can range from minutes to hours depending on Zoom's processing queue and configuration. This architecture fits post-call analytics, compliance archiving, CRM population, and meeting summaries where a short delay is acceptable.
- Real-time (media bot): A headless container joins the meeting via the Zoom Meeting SDK, captures raw PCM audio from callbacks, and streams it over WebSockets to your STT provider. You get partials in under 103ms and final transcripts in approximately 300ms with our Solaria-1 model. This architecture is required for live captions, real-time agent coaching, and any feature that needs transcript data before the meeting ends. For teams building meeting assistants, this architecture decision determines your entire integration surface.
Table 1: Build vs. buy decision matrix
| Dimension |
Native Zoom API (batch) |
Custom bot (real-time) |
| Transcript latency |
Minutes to hours post-meeting |
Sub-second partials, ~300ms final |
| Dev complexity |
Low (webhook + REST) |
High (SDK, containerization, WebSocket) |
| Infrastructure maintenance |
None |
Significant ongoing overhead |
| Accuracy control |
None (no fine-tuning options) |
Full (route to any STT provider) |
| Best for |
Archival, basic notes |
Real-time coaching, live captions |
Zoom native transcription API features
Zoom's native transcription depends on two configuration prerequisites: Cloud Recording must be enabled at the account or group level, and the Audio Transcript toggle must be enabled under Advanced Cloud Recording Settings. AI Companion is a separate feature for meeting summaries and does not affect whether you receive a word-for-word VTT transcript.
The recording.transcript_completed webhook event fires when the VTT transcript file is available. The download payload typically includes speaker labels that may be based on participant display names, though label quality can vary in larger meetings.
One gap that catches teams mid-sprint: Zoom's AI Companion meeting summaries and action items reportedly have limited API access. You can retrieve the raw VTT file but structured meeting intelligence that Zoom generates internally may not be accessible via standard REST endpoints. Any team building automated CRM population or coaching insights ends up running their own enrichment layer on top of the raw transcript regardless, which removes the primary justification for using native transcription at all.
Table 2: Use case to integration method mapping
| Use case |
Required method |
Native limitation |
| Post-meeting archival |
REST + recording.completed |
Minutes to hours latency |
| CRM auto-population |
REST + enrichment layer |
Limited structured output options |
| Real-time sentiment |
Media bot + streaming STT |
Not available natively for external use |
| Live agent coaching |
Media bot + streaming STT |
Not available natively for external use |
| Multilingual meetings |
Custom STT |
36-language support, limited code-switching |
When to BYO transcription models
Zoom's native engine has limited configuration options for vocabulary, speaker normalization, or code-switching. Per Zoom's published documentation, AI Companion supports up to 36 languages, Voice Translator is limited to 5 spoken languages, and language interpretation features can be initiated during meetings, though these capabilities may be limited for external API integration.
When you route audio to our API instead, you choose between two models built for different jobs. Solaria-3 handles real-world European business audio across English, French, German, Spanish, and Italian, ranking first on production recordings ahead of AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics. Solaria-1 is the model for real-time streaming, true mid-conversation code-switching, and coverage across 100+ supported languages.
Implementing batch transcription for Zoom meetings
Batch is the right architecture for post-call analytics, compliance archiving, meeting summaries, and CRM population where a few minutes of latency is acceptable.
1. Configure Zoom for audio processing
In the Zoom Web Portal, navigate to Settings > Recording and enable these settings:
- Cloud Recording at the account or group level.
- Record active speaker, gallery view, and shared screen under Cloud Recording layout options.
- Audio transcript under Advanced Cloud Recording Settings.
Without the "Audio transcript" toggle enabled, Zoom generates an M4A audio file but no VTT file, and the transcript endpoint returns a 404. This is the most common first-integration failure mode.
2. Secure your Zoom app connection
Create a Server-to-Server OAuth app in the Zoom Marketplace. This credential type authenticates background services without a user present. You'll need CLIENT_ID, CLIENT_SECRET, and ACCOUNT_ID from the app dashboard. In the app configuration, enable cloud_recording:read:recording:admin for the audio file and cloud_recording:read:meeting_transcript:admin for the transcript file. These are the granular scopes Server-to-Server OAuth apps use for recording access; the older recording:read:admin scope predates Zoom's granular scope system and isn't available on Server-to-Server apps.
```python
import requests
import base64
client_id = "YOUR_CLIENT_ID"
client_secret = "YOUR_CLIENT_SECRET"
account_id = "YOUR_ACCOUNT_ID"
credentials = base64.b64encode(
f"{client_id}:{client_secret}".encode()
).decode()
response = requests.post(
"https://zoom.us/oauth/token",
headers={
"Authorization": f"Basic {credentials}",
"Content-Type": "application/x-www-form-urlencoded"
},
data={
"grant_type": "account_credentials",
"account_id": account_id
}
)
access_token = response.json()["access_token"]
# see developers.zoom.us/docs/internal-apps/s2s-oauth/
```
Cache the token and refresh before expiry. Waiting for a 401 response adds latency to your first webhook-triggered job.
3. Automate Zoom transcript retrieval
Register a webhook endpoint for the recording.transcript_completed event. The payload includes a download_url and download_token for each file type. Filter for file_type == "TRANSCRIPT" to target the VTT file.
Zoom's rate limits apply to all API endpoints, with varying thresholds based on endpoint type. Build exponential backoff from day one: start at 2 seconds, double on each retry, cap at 60 seconds, and honor the Retry-After header on 429 responses.
One reliability gap to plan for: the Recording API returns files for meetings where Cloud Recording was enabled and completed successfully. Meetings that ended unexpectedly may not fire webhooks reliably. A media bot that captures audio independently is the only reliable fallback in those cases.
4. Parsing Zoom transcript metadata
The VTT file Zoom returns follows this structure:
```
WEBVTT
00:00:01.000 --> 00:00:03.500
Alex: We need to confirm the budget for Q3.
00:00:04.000 --> 00:00:07.200
Jordan: I'll send the updated forecast this afternoon.
```
VTT is a text-based format with timestamp ranges and speaker labels. Every downstream AI feature (action item extraction, CRM field population, coaching scores) runs on raw paragraph text, which limits structural precision throughout your pipeline.
Routing the same audio to our async API returns word-level timestamps, speaker labels powered by pyannoteAI's Precision-2 model, named entities, sentiment, and translation in a single response, structured and ready to route to any LLM via our audio-to-LLM pipeline.
Using a custom STT provider with Zoom
For async workflows, the integration path is significantly simpler than a media bot: download the raw audio Zoom generates, upload it to our API, and retrieve the enriched transcript.
Routing Zoom audio to external STT
After receiving recording.completed, download the M4A or WAV audio file using the download_url and download_token from the payload. Send it to our async transcription endpoint:
```python
import time
import requests
GLADIA_API_KEY = "YOUR_GLADIA_API_KEY"
def transcribe_zoom_recording(audio_url: str) -> dict:
headers = {
"x-gladia-key": GLADIA_API_KEY,
"Content-Type": "application/json"
}
payload = {
"audio_url": audio_url,
"diarization": True,
"diarization_config": { # see docs.gladia.io/api-reference/v2/pre-recorded/init
"min_speakers": 1,
"max_speakers": 8
},
"summarization": True,
"named_entity_recognition": True,
"sentiment_analysis": True,
"custom_vocabulary": True,
"custom_vocabulary_config": {
"vocabulary": ["your", "brand", "terms"]
}
}
response = requests.post(
"https://api.gladia.io/v2/pre-recorded",
headers=headers,
json=payload
)
result_url = response.json()["result_url"]
while True:
result = requests.get(result_url, headers=headers).json()
if result["status"] == "done":
return result
if result["status"] == "error":
raise RuntimeError(f"Transcription failed: {result}")
time.sleep(2)
```
This single call returns word-level timestamps, speaker labels, named entities, sentiment scores, and a summary. All features are included in the base rate on Starter and Growth plans, with no separate line items for diarization or translation; Enterprise pricing is custom and debundled.
Managing Zoom API latency at scale
Table 3: Transcript delivery latency comparison
| Method |
Availability |
Notes |
| Native Zoom AI |
Up to 24 hrs (or meeting duration) |
Depends on Cloud Recording queue |
| Zoom VTT download |
Typically 1-24 hrs post-meeting |
After recording.transcript_completed fires |
| Gladia async (1 hr audio) |
Under 60 seconds |
Full enrichment included |
| Gladia real-time (Solaria-1) |
~300ms final |
Media bot is the typical path for external audio capture from Zoom |
For teams building post-meeting summaries, the async path processes one hour of audio in under 60 seconds. A 45-minute meeting produces a full enriched transcript before attendees have finished their Slack follow-ups.
Estimating your Zoom API budget
Self-hosting a media bot carries meaningful engineering overhead for scaling, GPU provisioning, and version management, plus cloud compute costs that compound with call volume.
On our Growth plan, async transcription runs as low as $0.20/hr with diarization, translation, named entity recognition, sentiment analysis, and summarization all included. For 1,000 hours of Zoom meeting audio per month, that's $200/month with no add-on line items at our published rates. Compare that against providers like Deepgram or AssemblyAI where diarization and translation are separately metered: at scale, those add-ons can multiply effective cost by 2-3x.
Getting real-time transcripts from Zoom
Real-time transcription from Zoom requires a media bot because Zoom's Meeting SDK is the documented path to raw audio for external integration. External developers capture audio at the SDK level rather than through a native streaming API.
Automating bot joins via Zoom API
A real-time meeting assistant spawns a headless container that joins as a participant using the Zoom Meeting SDK. You trigger the join programmatically by accepting an invite URL or calling Zoom's meeting join API from your container. Middleware providers like Recall or MeetingBaaS abstract container orchestration and WebRTC lifecycle management if you want to skip building that infrastructure layer. Our LiveKit integration also provides a pre-built real-time audio routing path for teams already on that stack.
The bot participant appears in the meeting roster. Configure a display name like "Notetaker" to set user expectations.
Establishing WebSocket audio streams
The Zoom Meeting SDK provides a raw data interface for audio capture. The native SDK exposes callbacks for PCM audio data. Per Zoom's Meeting SDK documentation, audio is typically delivered at a 48kHz sample rate. If your downstream STT provider expects 16kHz (as shown in the code below), you'll need to resample the audio before streaming to avoid transcription timing issues.
Chunk the incoming PCM buffers and stream them over a WebSocket to our real-time API:
```python
import asyncio
import json
import requests
import websockets
GLADIA_API_KEY = "YOUR_GLADIA_API_KEY"
def start_live_session() -> str:
config = {
"encoding": "wav/pcm",
"bit_depth": 16,
"sample_rate": 16000,
"channels": 1,
"model": "solaria-1",
"language_config": {
"languages": [],
"code_switching": True
},
"messages_config": {
"receive_partial_transcripts": True,
"receive_final_transcripts": True
}
}
response = requests.post(
"https://api.gladia.io/v2/live",
headers={
"x-gladia-key": GLADIA_API_KEY,
"Content-Type": "application/json"
},
json=config
)
return response.json()["url"]
async def stream_zoom_audio(pcm_queue: asyncio.Queue):
websocket_url = start_live_session()
async with websockets.connect(websocket_url) as ws:
async def send_audio():
while True:
chunk = await pcm_queue.get()
if chunk is None:
break
await ws.send(chunk)
async def receive_transcripts():
async for message in ws:
data = json.loads(message)
if data.get("type") == "transcript":
is_final = data["data"]["is_final"]
text = data["data"]["utterance"]["text"]
label = "final" if is_final else "partial"
print(f"[{label}] {text}")
await asyncio.gather(send_audio(), receive_transcripts())
```
Keep chunk sizes between 100ms and 500ms to balance latency against WebSocket overhead.
Route audio to your STT provider
With the WebSocket connection established, Solaria-1 returns partials under 103ms and final transcripts in approximately 300ms. That budget is sufficient to feed a live UI or a streaming LLM pipeline without perceptible lag.
Speaker attribution for real-time streams works differently than async workflows. If you configure the Zoom SDK to route separate per-participant audio channels, you can assign speaker labels at the channel level. For mixed-stream configurations, speaker attribution needs to be handled in post-processing for higher accuracy using our async diarization pipeline once the meeting ends.
Handle interim and final transcripts
Our WebSocket API emits two transcript event types: partial (low-latency, may revise) and final (stabilized, high-confidence). For live UI updates, render partials and replace them on final receipt. For LLM pipeline inputs, buffer to final only to avoid sending unstable text to your model.
```python
if data.get("type") == "transcript":
is_final = data["data"]["is_final"]
text = data["data"]["utterance"]["text"]
if is_final:
commit_to_pipeline(text)
else:
update_live_display(text)
```
Handling inaccurate Zoom meeting transcripts
The most common failure mode after integration is accuracy degradation in production that wasn't visible in test audio. Test recordings are typically cleaner, better-paced, and more monolingual than real meetings.
Mitigating WER spikes for accented speech
Zoom's published benchmarks report a 6.57% WER on real meeting audio, though performance varies by language distribution, accent mix, and recording conditions.
When you route to Solaria-3, you get a model trained on real-world business audio: noisy recordings, variable mic quality, multiple speakers, and accented speech. Solaria-3 ranks first against AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics on production English recordings from real customers, achieving 6.4% WER on Earnings22 financial calls, the only model under 7% on that benchmark. For French, German, Spanish, and Italian business audio, the gap over native Zoom transcription is wider still.
Addressing non-English language gaps
Zoom's language ceiling and limited handling of mid-conversation language changes are the most common reasons teams move to a custom STT layer. When a speaker shifts from English to Spanish mid-sentence, Zoom either fails silently or transcribes the non-primary language as garbled output.
Our Solaria-1 model handles mid-conversation language changes across its full language set without session interruption, which matters most for APAC and LATAM-serving teams where multilingual meetings are standard.
Customizing vocabulary for STT accuracy
Both models support custom vocabulary injection to force correct transcription of brand names, product identifiers, and domain-specific jargon. Pass your terms at transcription initialization:
```json
{
"audio_url": "https://your-domain.com/meeting-audio.m4a",
"diarization": true,
"custom_vocabulary": true,
"custom_vocabulary_config": {
"vocabulary": [
"Solaria",
"Gladia",
"Salesforce CRM",
"MRR"
]
}
}
```
The advanced vocabulary format accepts pronunciation hints and intensity weighting for phonetically ambiguous terms:
```json
{
"vocabulary": [
{
"value": "Kubernetes",
"pronunciations": ["Koo-ber-neh-tees"],
"intensity": 0.6
}
]
}
```
Mitigating transcription hallucinations
Hallucinations in production STT (repeated phrases, invented words during silence, fabricated content at audio boundaries) tend to occur during low-energy segments: pauses, background noise, and crosstalk at meeting start and end. They surface in production and not in test sets because clean test audio rarely triggers the conditions that cause them.
Routing to Solaria reduces the surface area for these failure modes. Lower WER on conversational audio, with 6.4% on Earnings22 financial calls for Solaria-3, the only model under 7% on that benchmark, means fewer substitution errors that downstream summarization and entity extraction layers would otherwise inherit:
"Preferred vendor for speech-to-text speed & accuracy" - Verified user on G2
Validating Zoom API deployments at scale
Ensuring data residency and DPA compliance
Before routing customer audio to any third-party API, work through this compliance checklist:
- SOC 2 Type II and ISO 27001: We hold these certifications.
- GDPR: Our Data Processing Agreement (DPA) is available via our compliance hub.
- HIPAA: We hold this certification.
- Model training policy: Growth and Enterprise plans never use your audio for training, no opt-out required. The Starter plan may use data for training by default, so teams handling sensitive conversations should operate on Growth or Enterprise.
- Data residency: Dedicated cloud clusters in EU and US regions. On-premises and air-gapped deployment are not available on any plan.
"Accurate Fast and Developer Friendly Transcription API for Multilingual Audio" - Faess W. on G2
Diarization logic for Zoom streams
For async workflows, our diarization pipeline runs pyannoteAI's Precision-2 model over the full recording. This multi-stage pipeline (segmentation, embedding, clustering) operates on the complete audio context, which is why it consistently delivers lower diarization error rates than streaming alternatives. On average, our async diarization delivers 3x lower DER compared to alternatives.
Enable it in your transcription payload with "diarization": true. Pass speaker count hints via diarization_config when you know the expected participant count, which improves clustering precision for meetings with more than six speakers.
Managing API failures and retries
Design your webhook handler to be idempotent: Zoom may fire recording.completed more than once for the same meeting. Deduplicate on meeting_uuid and store processing state (pending, in-progress, complete, failed) in a durable store rather than in-memory.
For our API, implement exponential backoff on 5xx responses: start at 2 seconds, double on each retry, cap at 60 seconds, max 5 retries before dead-letter. Per Zoom's published API documentation, failed webhook deliveries are retried up to three times over roughly 85 minutes (at approximately 5, 25, and 85 minutes after the initial attempt), so if your endpoint is down longer than that you will miss events entirely.
Verifying WER for Zoom API data
Run a continuous evaluation pipeline against a held-out set of your own meeting recordings with human-verified transcripts. Select 50-100 representative recordings covering your actual language distribution, speaker mix, and noise conditions, and measure monthly.
For a quick gut-check without brand bias, upload up to two minutes of your Zoom audio to our blind STT comparison tool. It's transcribed by two providers and you pick the better output before seeing which engine produced it. For serious evaluation, run your audio against a reproducible benchmark before committing.
Start with €50 in free credits and have your Zoom integration in production in less than a day.
FAQs
Does Zoom provide a native real-time transcription API for external developers?
No. Zoom does not expose a direct streaming STT API for external use without the Meeting SDK. To access real-time audio for this integration pattern, you must deploy a media bot using the native Zoom Meeting SDK (C++/Linux), which captures raw PCM audio via the onMixedAudioRawDataReceived callback and streams it to an external STT provider over WebSockets.
What languages does Zoom transcription support?
Per Zoom's published documentation, AI Companion supports up to 36 languages with limited code-switching support, and Voice Translator is limited to 5 spoken languages. Routing audio to Solaria-1 covers 100+ languages with native mid-conversation code-switching.
How do you route Zoom streams to the Gladia API?
For async, download the M4A or WAV file from the recording.completed webhook payload and POST the audio URL to /v2/pre-recorded with your enrichment options. For real-time, deploy a Meeting SDK bot to capture PCM audio, POST your session config to https://api.gladia.io/v2/live to receive a session-specific WebSocket URL, then connect to that URL and stream chunked 16-bit PCM buffers
How fast does the Gladia async API process Zoom recordings?
Our async API processes approximately one hour of audio in under 60 seconds, returning a full enriched transcript with word-level timestamps, speaker labels, entities, and sentiment. Native Zoom AI processing can take up to 24 hours (or the duration of the meeting) depending on Cloud Recording queue depth and configuration.
Can I retrieve Zoom's "My Notes" AI summaries via API?
No. Zoom's AI Companion-generated meeting summaries and action items are not accessible via REST endpoints. You can retrieve the raw VTT transcript but must build your own enrichment layer for structured intelligence extraction, which is what our async API delivers in a single call.
What is the rate limit for Zoom's transcript download endpoint?
Per Zoom's published API documentation, the transcript download endpoint is classified as a Medium rate limit endpoint. High concurrent request volume will trigger throttling. Build exponential backoff (start at 2 seconds, double on retry, cap at 60 seconds) and honor the Retry-After header on 429 responses.
Key terms glossary
Word Error Rate (WER): The percentage of words incorrectly transcribed compared to a reference transcript, calculated as (substitutions + deletions + insertions) divided by total reference words. Lower WER indicates higher transcription accuracy.
Diarization Error Rate (DER): The percentage of time incorrectly attributed to speakers in a multi-speaker audio file. Our async pipeline uses pyannoteAI's Precision-2 model to minimize this error.
Server-to-Server OAuth: A Zoom authentication flow that allows background services to access APIs without a user present. Requires CLIENT_ID, CLIENT_SECRET, and ACCOUNT_ID credentials with a one-hour token TTL.
Code-switching: Mid-conversation language changes where a speaker shifts from one language to another within a single utterance. Solaria-1 handles this natively across its supported language set without session interruption.
PCM (Pulse-Code Modulation): A digital representation of analog audio signals where the amplitude is sampled at regular intervals and stored as numeric values. Per Zoom's Meeting SDK documentation, audio is delivered in 16-bit PCM format at 48kHz, which must often be resampled to 16kHz before streaming to speech-to-text APIs.
STT (Speech-to-Text): The process of converting spoken audio into written text using machine learning models. Also referred to as ASR (Automatic Speech Recognition) or transcription.
Media bot: A headless container that joins a Zoom meeting as a participant via the Meeting SDK to capture raw PCM audio for real-time processing. Required for sub-second transcript latency on Zoom specifically.
VTT (WebVTT): A text-based file format for timed text tracks, used by Zoom to deliver transcript files with speaker labels and timestamp ranges but no word-level timestamps or confidence scores.
