API Endpoint(s) and/or Zoom API Event(s) /users/<userid>/recordings /meetings/<meetingId>/recordings
Description
I’m looking to retrieve transcripts for meetings that occurred prior to setting up webhooks.
The transcripts are downloadable at: https://us06web.zoom.us/recording/management/meeting/transcript.
Clicking on the download link successfully downloads the files.
For some transcripts, when trying to download the transcript via the REST API:
- /users/<userid>/recordings?meeting_id=<meeting_id>
is missing the entire meeting in the meetings[] even with the meeting date within the last 30 days. The API returns a 200 OK with a valid response, but the meetings[] is empty. The recordings are available on the web site.
/meetings/<meetingId>/recordings
returns a 404.
{
"code": 3301,
"message": "This recording does not exist."
}
despite the transcript for a meeting_id being available on the website. I’m passing the 11 digit meeting Id shown on the web portal with the spaces removed.
Update /users/<userid>/recordings with the URL encoded meeting uuid succeeds for more meetings than passing the 11 digit meeting_id or calling the meetings endpoint at /meetings/<meetingId>/recordings with the 11 digit meeting id. Passing the URLencoded uuid for the meeting seems to always result in a 404.
Error?
See above
How To Reproduce Steps to reproduce the behavior:
Behavior is inconsistent. Downloading transcripts via the API works for about 30% of the downloads available on the website
Based on the details you’ve shared, here are a few possibilities that might explain the behavior:
API Scope vs. Dashboard Aggregation: The web dashboard aggregates across all users, regions, or accounts tied to your Zoom instance, while the /users/<userid>/recordings endpoint is scoped to a specific user in a specific region. If the recording was hosted by a different user or stored in a different region, it might not appear in the API response for the you’re querying.
Processing Delays (Unlikely): Even though the recordings are from meetings within the last 30 days, there could be a delay in how Zoom processes them for API access, especially for meetings that occurred before webhooks were set up. The dashboard might reflect an expedited view of available recordings, while the API lags slightly until the data is fully indexed.
Expiration (Unlikely): Recordings typically expire after a set period (e.g., 30 days) depending on your Zoom plan, but since they’re still accessible in the dashboard, this doesn’t seem to be the issue—just worth noting for future reference.
Here’s a quick troubleshooting plan you could try:
Fetch the UUID: Use /past_meetings/<meetingId>/instances with the 11-digit Meeting ID to get the UUID for the specific meeting instance, then query /meetings/<uuid>/recordings.
Broad Query: Call /users/<userid>/recordings without the meeting_id filter, using from and to parameters (e.g., ?from=2025-02-12&to=2025-03-12) to see if the recording appears in the full list.
Check Permissions: Confirm the <userid> has access to the recording (e.g., was the host or has account-level visibility).
As an alternative, you might explore the Recall.ai It simplifies fetching recordings and transcripts through a unified interface.
All transcripts were created within the last 30 days. They are on the WebPortal. Processing should be complete.
None of the API calls results in a 400 Bad request stating the missing permissions or a 401 error. It’s probably not a permission issue.
/users/<userid>/recordings?meeting_id=<urlencoded-uuid>&from=<today-30days> returns more transcripts than /users/<userid>/recordings?meeting_id=<11didigitid>&from=<today-30days>, but not all transcripts available on the portal.
/past_meetings/<11digitmeetingid>/instances does give the uuid, which is also available in /users/<userid>/meetings and users/<userId>/recordings.
/meetings/<urlencoded-uuid>/recordings - seems to consistently return a 404. Is there another trick for passing the uuid?
I will look into the regions of the users. They all should be in the same region, but it’s definitely worth a look.