How to get recordings from Zoom

//@title pages/api/startRecall.ts
const botResp = await fetch(`https://${RECALL_REGION}.recall.ai/api/v1/bot`, {
  method: 'POST',
  headers: { authorization: process.env.RECALL_API_KEY },

body: JSON.stringify({
  meeting_url : zoomLink,
  external_id : externalId,
  metadata    : { external_id: externalId },
  webhook_url : 'https://your-app/api/webhook',

  recording_config: {
    video_mixed_mp4   : {},
    audio_mixed_mp3   : {},
  }
})
})

//@title pages/api/webhook.ts
import type { NextApiRequest, NextApiResponse } from 'next'
import http from 'http'
import { prisma } from '../../lib/prisma'

export const config = { api: { bodyParser: false } }

export default async function handler (
  req: NextApiRequest,
  res: NextApiResponse
) {
  const chunks: Uint8Array[] = []
  for await (const c of req) chunks.push(c)
  const raw    = Buffer.concat(chunks)
  const rawStr = raw.toString('utf8')

  let ev: any
  try { ev = JSON.parse(rawStr) }
  catch { res.status(400).end('Invalid JSON'); return }
// Handle post-call recording metadata for recordings
  if (ev.recording?.id) {
    const externalId = ev.external_id
    const meeting = await prisma.meeting.findUnique({ where: { externalId } })
    if (!meeting) return res.status(404).end('Meeting not found')
//Store recording metadata (e.g. to retrieve MP4/MP3 later via download_url)
    await prisma.meeting.update({
      where: { id: meeting.id },
      data : {
        recordingId: ev.recording.id,
        videoUrl   : ev.video_url ?? null
      }
    })
    return res.status(200).end('Post-call stored')
  }
  res.status(200).end('No action')
}

const videoUrl = `https://us-east-1.recall.ai/api/v1/video_mixed?recording_id=RECORDING_ID_HERE`

const res = await fetch(videoUrl, {
  headers: {
    'Authorization': `Bearer ${process.env.RECALL_API_KEY ?? ''}`,
    'Accept': 'application/json'
  }
})

if (!res.ok) {
  throw new Error(`Failed to fetch video: ${res.statusText}`)
}

const data = await res.json()
const downloadUrl = data.results?.[0]?.data?.download_url

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "recording": {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "metadata": {
      "additionalProp": "string"
    }
  },
  "created_at": "2025-08-01T04:05:14.009Z",
  "status": {
    "code": "processing",
    "sub_code": "string",
    "updated_at": "2025-08-01T04:05:14.009Z"
  },
  "metadata": {
    "additionalProp": "string"
  },
  "data": {
    "download_url": "string"
  },
  "format": "mp4"
}

Methods to get recordings from Zoom

While Recall.ai is the best fit if you want flexibility, speed, and reliability, here are all the other viable options you might consider.

Alternative 1: Zoom Cloud Recording API

Why you’d use this

You want a Zoom native way to fetch recordings without building bots or custom infrastructure. You’re comfortable waiting until well after the meeting ends.

How it works

• Meeting hosts must enable Cloud Recording in Zoom.
• Host of the meeting presses the record button during each meeting
• After a call ends and Zoom processes it, the recording.completed webhook fires.
• Your backend fetches MP4/MP3 files via Zoom’s REST API using the recordingId.

Benefits

• Zoom native: This is a first-party Zoom integration. Because it’s managed by Zoom, you don’t need to worry about maintaining bots, browser automation, or custom media infrastructure. Zoom is responsible for ingesting, encoding, and storing the recordings, and you fetch the finished files.
• No additional participant: Recordings are generated directly by Zoom, not by a bot joining the meeting. This makes it useful in cases where an in-meeting participant isn’t desirable or allowed.
• Variety of meeting artifacts: Depending on account settings, recordings can include not just MP4/MP3 media, but also chat logs, participant lists, and other metadata that can be valuable for post-meeting workflows.

Drawbacks

• Delayed, post-meeting availability: Recordings are only accessible after the meeting ends, and Zoom requires additional time to process them. There is no way to access live media through this method. Availability typically lags behind the meeting’s duration—for example, a 1-hour meeting may take another hour or more before the MP4 is ready.
• Host setup and action required: Cloud Recording must be enabled at the account or user level, and the host (or a participant with recording privileges) has to remember to start the recording during the meeting. If you are not the host you cannot record the meeting.
• Access restrictions: Only hosts or users with appropriate permissions (via Zoom OAuth scopes) can retrieve recordings, which limits usefulness in cross-organization contexts.
• Paid plan requirement: Cloud Recording is only available on Zoom’s paid plans. This means that any end users who are on free-tier will not be able to access this functionality.
• OAuth + app review: Users have to connect their Zoom accounts via OAuth, which can add onboarding friction. In addition, you’ll need to publish a Zoom app and go through Zoom’s review process before using it in production. The review process typically takes around 4 weeks.

Who should use this

Teams building for Zoom admins/hosts who already use cloud recording and are okay with async delivery.

Alternative 2: Custom live streaming (RTMP)

Why you’d use this

You need to view or record a meeting without bots, using Zoom’s built-in streaming features.

How it works

• Configure live streaming: The host enables Custom Live Streaming in Zoom and points it to your RTMP endpoint. This can be done in account settings or on a per-meeting basis.
• The user needs to start the stream during the meeting: By default, the host needs to manually start live streaming from the Zoom UI once the meeting is running. Until the stream is started, no media will be sent. Alternatively, live streaming can be pre-configured in Zoom settings or triggered via the API to avoid the manual step.
• Push during the meeting: When the meeting starts, Zoom sends a single program feed (mixed audio and video) to your RTMP server (e.g., Nginx-RTMP, Cloudflare, Mux).
• Ingest the stream: Your server receives the feed in real time and can either transcode it, pipe it into another service, or rebroadcast it.
• Record or process: Store the RTMP feed or process it live.

Benefits

• Continuous feed during the meeting: Zoom pushes audio and video to your RTMP server as the meeting happens, suitable for rebroadcasting or delayed-live monitoring.
• Straightforward server-side recording: Once ingested, the stream can be recorded using standard RTMP tools, with no custom Zoom media pipeline required.
• Ideal for meetings where bots aren’t appropriate: Since the stream comes directly from Zoom, nothing joins the meeting. This can be useful in cases where an in-meeting bot isn’t desired.

Drawbacks

• Host action required: Someone must start the stream each time, unless pre-configured in meeting templates or account settings. This adds manual steps which are prone to human error.
• Single mixed feed: RTMP provides one composite audio/video stream only. You can’t capture per-participant audio or video tracks for finer-grained analysis. You don’t get speaker names using RTMP so you’ll need to use machine diarization to separate speakers.
• Host-controlled layout and quality: The stream’s layout (speaker view, gallery view), resolution, and bitrate are dictated by the host’s settings and Zoom account level. This limits flexibility if you need standardized outputs.
• Paid account + settings required: The host must be on a paid Zoom plan, and the “Allow livestreaming of meetings” setting has to be enabled. If it’s disabled or locked at the group/account level, users will need admin support to turn it on. The good news is that this only needs to be done once per account.
• Live streaming badge: Zoom displays a “live streaming” badge to all participants for compliance reasons. This cannot be removed and may cause some participants to feel uncomfortable.
• High latency: RTMP typically has 10–30s of latency. This is fine for most use cases, but not suitable if you need near real-time audio.
• Limited metadata: RTMP streams don’t include per-word timestamps or detailed meeting artifacts. If your product depends on timestamped transcripts (e.g., click-to-seek playback), you’ll need to build that layer yourself.

Who should use this

Best for rebroadcast use cases (such as observer rooms) or when you want an audio/video feed without running bots and do not need near real-time audio.

Alternative 3: Build your own bot

Why you’d use this

You need direct, per-participant access to Zoom’s underlying audio and video streams.

How it works

• Join as a bot client: You build a custom Zoom client with the Meeting SDK (Windows, macOS, Linux). This “raw data bot” joins the meeting as a participant, but without UI.
• Enable raw data mode: The SDK exposes special callbacks that provide raw audio (PCM) and video (YUV) frames.
• Consume the data: In your client code you can encode the streams for storage, pipe them to your backend for processing, or render the data in your UI.
• Manage distribution: Since you’re effectively shipping a Zoom-powered client, your app must handle packaging, deployment, and updates across platforms.

Benefits

• Direct raw media: Unlike artifacts or RTMP feeds, you get the actual PCM/YUV frames, which means you can choose your own codecs, quality settings, or processing pipeline.
• Per-participant streams: Audio and video are available per user instead of only as a mixed feed. This is critical for accurate transcription, speaker diarization, AI-driven analytics, or training data where you need to separate who said what.
• Real-time processing: Since frames arrive live, you can run transcription, sentiment analysis, or computer vision models as the meeting happens rather than waiting for post-call artifacts.
• Works on free Zoom plans: Unlike cloud recording or RTMP, bots can record meetings even if the host is on a free Zoom account.
• Non-host recording: Bots can capture the meeting even if your user is not the host, as long as the bot is admitted into the meeting.
• Low latency: Bots connect directly to the meeting, typically delivering media with 200–500 ms latency—fast enough for real-time analysis.
• Consistent cross-platform UX: The bot-based recording experience is consistent across Zoom, Meet, Teams, and Webex (though you need separate implementations per platform).

Drawbacks

• Client ownership: You must distribute and maintain a Zoom-based app across OSes. That means packaging, updates, and support which is a much heavier lift than calling an API.
• High engineering overhead: Handling raw media requires you to manage encoding, synchronization, and storage, often with GPU/CPU optimizations. This is far more complex than downloading Zoom’s processed recordings.
• Significant build effort: Building a stable, scalable recording bot can take a skilled engineering team a year or more. Each platform (Zoom, Meet, Teams, Webex) requires a separate implementation.
• Ongoing maintenance burden: Meeting platforms frequently update their SDKs and behaviors. Keeping bots reliable at scale often requires several full-time engineers to monitor, patch, and operate the infrastructure.
• Operating costs: Each bot runs as a full Zoom client instance in your infrastructure, which can be expensive to host until you reach economies of scale.
• Consent UX burden: Unlike Zoom’s built-in recording, raw data capture isn’t visible to participants by default. You’ll need to design your own notifications and consent flows to stay compliant with privacy laws.

Who should use this

This option is best for teams who need per-participant audio and video, are comfortable managing media encoding and compliance.

If you’re interested in building your own bot, check out the blog we wrote on how to build a zoom bot.

Alternative 4: Local desktop recording

Why you’d use this

You want a local, discrete form factor that captures Zoom calls directly on a user’s device without relying on bots or Zoom’s APIs.

How it works

• Capture video: The app records the Zoom meeting window (or screen region) directly.
• Capture audio: System audio is captured via OS APIs (e.g., WASAPI on Windows, ScreenCaptureKit on macOS) or loopback drivers (e.g., BlackHole, VB-Cable).
• Capture speaker names and metadata: Scrape speaker names and metadata or accessibility APIs if available.
• Record or stream: The app either saves recordings locally (MP4, WAV, etc.) or streams the captured media to a backend for processing and storage.
• Run locally: Everything happens on the user’s device, with no external Zoom integration or bot participant involved.

Benefits

• No Zoom admin setup: You don’t need to enable cloud recording or configure Zoom APIs, so it works even in organizations with restrictive Zoom settings.
• User-controlled: Can be distributed as a lightweight companion app that end users install and run. This avoids dependency on Zoom Marketplace approvals or admin permissions.

Drawbacks

• Installation + permissions: Requires users to install audio loopback drivers or grant OS-level screen/audio capture permissions. These can be blocked by enterprise IT policies or require elevated privileges, which adds friction to adoption.
• Reliability + quality risks: Recordings depend on the user’s environment. If they close the Zoom window, change displays, or misconfigure audio, the capture may fail or be incomplete. Video resolution is tied to the size of the captured window, not the underlying stream.
• Compliance burden: Unlike Zoom’s built-in recording, there’s no automatic “recording” banner visible to other participants. You must implement your own consent notifications to stay compliant with local privacy laws.
• Cross-platform & environment variability: Desktop apps run in highly varied end-user environments due to the variety of different OSes (macOS, Windows, Linux), versions, hardware (CPUs/GPUs), drivers, and enterprise security tools. Supporting all of this increases the surface area for bugs and raises the cost of testing, packaging, auto-updates, and support.
• Battery + performance impact: Continuous video and audio capture can drain laptop batteries quickly, especially on long meetings. High CPU and GPU usage for real-time encoding may cause fans to spin up, apps to slow down, or the device to overheat. This can degrade both recording quality and the user’s overall experience. While it’s possible to optimize by using efficient codecs, leaning on built-in hardware for video encoding and by adjusting recording quality based on system load, those optimizations are tough engineering problems to solve reliably across all platforms.

Who should use this

This option is best for teams that need a non-bot, local form factor. It’s useful when working with organizations that don’t want meeting bots or API dependencies but are comfortable with users installing a desktop companion app. These teams are willing to distribute and maintain a desktop app, and are comfortable handling local capture quirks like audio drivers and OS permissions.

If you like the desktop app form factor but want to skip the complexity of audio drivers, screen capture APIs, and cross-OS packaging, Recall.ai offers a Desktop Recording SDK that provides transcripts with speaker names, audio, and video directly from the user’s device. It records meetings reliably without requiring bots or third-party drivers, making it a faster way to productionize this approach.

Recording formats accessible using the Meeting Bot API

Recall.ai delivers recordings in real time or after the call, depending on your bot configuration. Delivery happens through webhooks, WebSocket, or by polling the API.

Recordings

Format	Timing	Access	Notes	API Docs URL
Mixed MP4 / MP3	Post-call	/video_mixed, /audio_mixed APIs	Combined audio/video of all participants	https://docs.recall.ai/reference/video_mixed_retrieve
Speaker-separated (Audio/Video)	Real-time or Post-call	/video_separate, /audio_separate APIs or WebSocket	Per-participant media; use real-time for analysis tools	https://docs.recall.ai/docs/how-to-get-separate-videos-per-participant-async https://docs.recall.ai/docs/how-to-get-separate-audio-per-participant-async
RTMP (Live)	Real-time	RTMP stream or video_mixed_flv.data via WebSocket	Ideal for live rebroadcast or human viewing	https://docs.recall.ai/docs/stream-real-time-video-rtmp
Raw Audio / Video Frames	Real-time	WebSocket	Raw 16kHz PCM audio and 360p PNG video frames (\~2fps)	https://docs.recall.ai/docs/real-time-audio-protocol https://docs.recall.ai/docs/real-time-video

Other Common Questions

Can I download a Zoom recording if I am not the host?

You can download a recording that was made using Zoom’s Cloud Recording API if the host (or an account admin) shares a cloud recording with you and enables download (or you have Recording Management permissions in the same Zoom account). You cannot download someone else’s local recording; the host must share the file. If you use Recall.ai’s Zoom Meeting Bot API, you can get the recording for any bots you send to a meeting. You can also get the recording for any bots for which you have the bot id and API key.

Where are my Zoom recordings being saved?

• Cloud recording: In the Zoom web portal under Recordings for the host’s account.
• Local recording: On the host’s computer (default folder is Documents/Zoom on Windows/macOS unless changed in Settings → Recording).
• Recall.ai’s Zoom Meeting Bot API: In your storage solution and/or Recall.ai can store the data for you.

Is there any way to download a Zoom recording?

• Using Zoom’s Cloud Recording API
• Host/admin: Sign in to the web portal → Recordings → Cloud Recordings → Download.
• Non-host: Use the host’s share link with download enabled, or ask the host to send the file. For local recordings, the host must provide the files (e.g., MP4/M4A/VTT).
• Recall.ai
• Call the Retrieve Bot endpoint as mentioned in Step 2 and use the download_url to get the recording.

Can I use a browser extension to get recordings from Zoom?

Most people run Zoom via the desktop client, not in the browser. That means any browser-only method (e.g., Chrome extensions that capture tab audio/video) won’t work unless the user explicitly stays in the Zoom web client, and most people join Zoom from the desktop client.