How to Record a Zoom Meeting: Native Settings and API Guide

Zoom's built-in recording works fine until you need 50 simultaneous meetings recorded without a host present, or until you need transcripts delivered to your application automatically, or until you realize cloud recordings only go to one account and your team has meetings spread across dozens of workspaces. The native tools were designed for individuals saving calls to watch later. They were not designed for programmatic pipelines.

Most engineering teams discover this gap when they try to build something on top of Zoom recordings: a sales coaching tool, an automated note-taker, a compliance archive. They start with the Zoom API, hit the approval process and permission requirements, and either abandon the project or spend weeks navigating Zoom's developer ecosystem.

This guide covers both paths. Native Zoom recording for straightforward use cases, and the MeetStream recording bot API for when you need programmatic control, automatic transcription, and webhook delivery at scale.

In this guide, we'll cover how native Zoom recording works (local and cloud), the limitations that push teams toward API-based approaches, how to deploy a Zoom recording bot with automatic leave configuration, and how to retrieve transcripts via webhook. Let's get into it.

Native Zoom recording: local and cloud options

Local recording saves the meeting file directly to your computer. It's available to all Zoom account types including free accounts. The host or a participant with host permission must start it manually. When the meeting ends, Zoom converts the recording to MP4, M4A (audio), and a chat text file. The files land in a folder on your local drive, typically `~/Documents/Zoom`.

The limitation is obvious: local recordings require someone to be present and click start. They also can't be automated, can't be pushed to a central system without manual upload, and can't be processed programmatically without additional tooling.

Cloud recording is available on paid Zoom plans (Pro and above). It stores recordings on Zoom's servers and sends participants an email with a link when processing finishes. The Zoom web portal gives you access to cloud recordings, and the Zoom API lets you retrieve them programmatically once you have the right permissions.

The Zoom Cloud Recording API requires OAuth authentication with the recording:read scope, and accessing recordings across multiple accounts requires admin-level credentials or a Zoom marketplace app approval. For teams recording meetings across many workspaces they don't own, this model breaks down quickly.

Zoom App Marketplace requirement for API access

Zoom requires that applications accessing meeting data via their API be registered in the Zoom App Marketplace. This applies to the recording API, the meeting data API, and any integration that joins meetings programmatically under your own credentials.

For internal tooling where you control all the Zoom accounts involved, this is manageable. You create a Server-to-Server OAuth app, get credentials, and access recordings within your account ecosystem. For external-facing products where users bring their own Zoom accounts, you need a full Marketplace listing, a security review, and ongoing compliance with Zoom's terms.

MeetStream's Zoom integration handles the platform credential layer. When you send a bot to a Zoom meeting via the MeetStream API, you provide the meeting URL. MeetStream's infrastructure handles the Zoom-side authentication. You still need to configure a Zoom app (the docs at docs.meetstream.ai walk through the setup), but you don't need your own marketplace listing for basic recording use cases.

Recording Zoom meetings via the MeetStream API

Once your Zoom integration is configured, deploying a recording bot takes a single API call. The bot joins the meeting as a named participant, records audio and video, and delivers processed artifacts to your webhook endpoint.

Here's a complete example with automatic leave configuration, which is important for unattended recording bots:

curl -X POST https://api.meetstream.ai/api/v1/bots/create_bot \
  -H "Authorization: Token YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "meeting_link": "https://zoom.us/j/123456789?pwd=abc123",
    "bot_name": "Recording Bot",
    "callback_url": "https://yourapp.com/webhooks/meetstream",
    "video_required": true,
    "recording_config": {
      "transcript": {
        "provider": {
          "name": "deepgram"
        }
      },
      "retention": {
        "type": "timed",
        "hours": 48
      }
    },
    "automatic_leave": {
      "waiting_room_timeout": 300,
      "everyone_left_timeout": 60,
      "voice_inactivity_timeout": 1800,
      "in_call_recording_timeout": 7200
    }
  }'

The automatic_leave block is particularly important for unattended bots. Here's what each field controls:

waiting_room_timeout: how many seconds to wait in the Zoom waiting room before giving up. Set this to avoid bots hanging indefinitely if nobody admits them. everyone_left_timeout: how many seconds after the last participant leaves before the bot also exits. voice_inactivity_timeout: seconds of silence before the bot leaves, useful for catching meetings that ended without a formal close. in_call_recording_timeout: hard maximum recording duration in seconds, a safety valve for runaway meetings.

For scheduled meetings, use the join_at parameter with an ISO 8601 timestamp. The bot queues and joins approximately three minutes before that time, no separate scheduling system required on your end.

Handling the webhook lifecycle

Your callback_url receives a sequence of events as the bot moves through the meeting. A solid webhook handler is the difference between a reliable recording pipeline and one that loses data intermittently.

The event sequence is: bot.joining when the bot enters the Zoom waiting room, bot.inmeeting when it's admitted and recording starts, bot.stopped when the meeting ends, and then asynchronous processing events: audio.processed, video.processed, and transcription.processed.

The bot_status field in the bot.stopped event tells you how the meeting ended. Stopped is a clean exit. NotAllowed means the waiting room timeout was hit without admission. Denied means the host removed the bot. Error means a platform-side issue.

// Example webhook handler (Node.js)
app.post('/webhooks/meetstream', (req, res) => {
 const { event, bot_id, transcript_id, bot_status } = req.body;

 switch (event) {
 case 'bot.inmeeting':
 console.log(`Bot ${bot_id} is recording`);
 break;

 case 'bot.stopped':
 if (bot_status === 'Stopped') {
 // Meeting ended cleanly, wait for processing events
 db.updateSession(bot_id, { status: 'processing' });
 } else if (bot_status === 'NotAllowed') {
 // Bot was never admitted, alert or retry
 alertTeam(bot_id, 'Bot not admitted to waiting room');
 }
 break;

 case 'transcription.processed':
 // Safe to retrieve transcript now
 fetchAndStoreTranscript(transcript_id);
 break;
 }

 res.sendStatus(200);
});

Always respond to webhooks with a 200 status quickly. If your processing logic is slow, queue the work and respond immediately. MeetStream retries failed webhook deliveries, but acknowledging promptly is cleaner.

Retrieving the transcript

Once you receive the transcription.processed event, the transcript is ready. Use the transcript_id returned in the original create_bot response:

curl -X GET https://api.meetstream.ai/api/v1/transcript/TXN_ID/get_transcript \
  -H "Authorization: Token YOUR_API_KEY"

The response includes speaker-diarized segments with timestamps. Each segment identifies the speaker by name (pulled from the meeting participant list), the start and end timestamps, and the text. This structure works directly as input for summarization models, CRM note fields, or search indexing.

Zoom supports real-time transcription as well, via the live_transcription_required parameter on create_bot. Pass a webhook_url and you'll receive transcription segments as the meeting progresses, rather than waiting for the full post-call processing. This is useful for live coaching overlays or real-time meeting intelligence applications.

Tradeoffs and what to watch for

The bot appears in the Zoom participant list. Zoom's terms of service require meeting participants to be informed when a recording is in progress, which applies whether you're using native recording or a bot. Make sure your use case complies with consent requirements in your jurisdiction.

Zoom's waiting room feature is the most common failure point for unattended bots. If the host has a waiting room enabled and isn't available to admit the bot, you'll hit the waiting_room_timeout. For internal team meetings where you control the calendar, you can disable waiting rooms for specific meetings or add the bot as a trusted contact. For external sales calls, plan for this case in your error handling.

Recording processing time scales with meeting length. A 30-minute call is typically processed and transcribed within five minutes of the meeting ending. A two-hour meeting might take fifteen minutes. Build your downstream workflows to be event-driven off webhooks rather than polling, and you won't have to worry about timing.

How MeetStream fits in

MeetStream handles the recording bot infrastructure, Zoom authentication management, transcription pipeline, and webhook delivery. The API surface is a single create_bot endpoint plus webhook handler. If you're also recording Google Meet or Teams calls, the same API works for all three platforms with the same request structure, which simplifies your integration significantly compared to managing separate platform integrations.

Conclusion

Native Zoom recording covers simple human-driven workflows. When you need to record Zoom meetings programmatically, at scale, with automatic transcription and webhook delivery, the bot API approach is more reliable. The key elements are: configure your Zoom integration once, POST to create_bot with your meeting URL and automatic_leave parameters, handle the webhook lifecycle in your callback URL, and retrieve transcripts once transcription.processed fires. The automatic_leave configuration is essential for unattended bots to handle waiting room timeouts and meetings that end in edge cases.

Get started free at meetstream.ai or see the full API reference at docs.meetstream.ai.

Frequently Asked Questions

How do I record a Zoom meeting without a host present?

Native Zoom recording requires manual action from a host or co-host. For automated, unattended recording, a bot API approach works better. Deploy a recording bot via the MeetStream API with automatic_leave configured, and the bot joins, records, and exits without any human intervention. The bot appears in the participant list as a named attendee.

What Zoom plan do I need for cloud recording?

Zoom cloud recording requires a paid plan, Pro or above. Free Zoom accounts are limited to local recording only. Local recording saves to your computer and requires manual management. Programmatic recording via a bot API works regardless of the meeting host's Zoom plan, since the bot brings its own recording capability as a participant.

Does the Zoom recording bot work for meetings I'm not hosting?

Yes. The recording bot joins as a participant, so it works for any meeting where it can be admitted. If the meeting has a waiting room, the host needs to admit the bot, or waiting room can be disabled. For meetings you host, the bot can be admitted automatically. Set waiting_room_timeout in the automatic_leave config to handle cases where the bot isn't admitted promptly.

How long after a Zoom meeting is the transcript available?

Transcript availability depends on meeting length and the transcription provider you select. For a 30-minute meeting, expect the transcription.processed webhook within three to eight minutes of the meeting ending. For longer meetings, processing takes proportionally longer. Use webhook-driven retrieval rather than polling to handle variable processing times cleanly.

What is the Zoom App Marketplace requirement for recording bots?

Applications that access Zoom meeting data via Zoom's own API need Marketplace registration. MeetStream's approach uses its own bot infrastructure to join meetings as a participant, which simplifies the setup. You configure a Zoom integration once in the MeetStream dashboard rather than maintaining a full Marketplace listing, though some Zoom configuration is still required for the bot to join meetings in your Zoom environment.