Topic Title:download_url returns HTML Login Page (200 OK) instead of MP4 via Webhook
Topic Body:
API Endpoint(s) and/or Zoom API Event(s)
Event: recording.completed Webhook
Endpoint involved: The download_url provided in the webhook payload for MP4 files.
Description I am developing a backend application (Node.js/Firebase) that listens for the recording.completed webhook to download and archive meeting recordings.
The Workflow:
My server receives the recording.completed webhook.
It extracts the download_url and the download_token from the payload.
It initiates a GET request to the URL, appending the token as a query parameter: ?access_token={download_token}.
The Problem: Instead of receiving the video file stream, my server receives a Status 200 OK response with Content-Type: text/html. The body of this response is an HTML page (“Download has been disabled by the administrator (200)”), causing my download logic to fail.
Crucial Context:
If I paste the exact same constructed URL (url + token) into a browser where I am logged in as the Account Admin, the download starts immediately.
If I paste the URL into an Incognito window (simulating the backend’s unauthenticated state), I get the HTML error page.
Error? No 403/401 error code is returned.
Status:200 OK
Content-Type:text/html;charset=utf-8
Response Body: HTML content (Login page or “Download has been disabled by the administrator (200)” page) instead of video/mp4.
How To Reproduce Steps to reproduce the behavior:
Request: GET request to download_url from recording.completed payload.
Zoom has been tightening this up, and many “200 OK + HTML login/blocked page” responses happen when the token is passed through the URL because the token isn’t honored. You can use the webhook’s download_token as a Bearer token in the Authorization header, per Zoom’s guidance on downloading recordings via webhooks and the broader access-token change notes about moving tokens out of query parameters
If you still get “Download has been disabled by the administrator (200)”, it could be an account policy, not an auth bug: downloading is disabled or restricted to admins/recording managers. Have an admin review cloud recording settings (who can download) and the sharing permission “Viewers can download” under managing and sharing cloud recordings
Subject: Update: Switched to Header Auth + Video SDK Settings Missing
Hi Amanda,
Thanks for the guidance. I wanted to share a few updates and a specific blocker I’m facing now.
1. Applied Your Fix (Header Auth): I successfully updated my code to pass the download_token via the Authorization: Bearer header (instead of the URL query param). I also located the token correctly in the root of the request body (since I am using the Video SDK event session.recording_completed).
2. The Current Error: Even with the correct Header method and a valid token, I am still receiving the 200 OK + HTML response saying:
“Download has been disabled by the administrator”
3. Missing UI Settings: You mentioned checking the “Viewers can download” or “Cloud recording downloads” settings in the dashboard. However, i guess because this is a Zoom Video SDK account, those specific settings appear to be completely missing from my interface.
I cannot see a “Share” button on the recording detail page.
I cannot find the “Cloud recording downloads” toggle in Account Settings.
Following up on my previous message, I am now able to attach screenshots to clarify the issue.
As mentioned, because this is a Zoom Video SDK account, the settings you recommended appear to be completely missing from my dashboard:
Yes, the issue is still persisting as of today (Feb 3).
To clarify my environment: I am using the Zoom Video SDK, and my backend listens for the session.recording_completed webhook event.
The Problem: When I use the download_token from this webhook (passed via Authorization: Bearer header), I receive a 200 OK response with an HTML body stating:
“Download has been disabled by the administrator”
Subject: Resolved - Issue was related to Content-Type headers
Hi Elisa,
I’m closing this request as I’ve identified the root cause on my end.
It appears that the recording download stream was returning a Content-Type of application/octet-stream rather than video/mp4 in this specific environment. My validation logic was strictly expecting video/ headers, which caused my system to reject the stream and throw the error.
I have updated my handling to accept application/octet-stream and the downloads are working correctly now.
