API Endpoint(s) and/or Zoom API Event(s) recording.completed webhook
Description
I have a legacy application with zoom where we emit the recording.completed webhook and listen for it in our application. We fixed some issues but are now not receiving “recording.completed” webhook events and would like assistance with this.
details
We recently fixed an issue where the validation webhook was not being handled and have been able to verify this is now working. When I initially tried to validate with our historic webhook, it indicated “success” in the UI but refreshing the page reverted the status back to an error. Ultimately, we deleted the old webhook and added a new one with the exact same configurations, tested the validation, and verified that the “validated” status now persists.
However, I am trying to test the overall end to end flow and have noticed that our application is not receiving webhooks from zoom.
I reviewed the documentation and noticed that it mentions “To receive recording.completed, you’ll need cloud_recording:read:recording or cloud_recording:read:recording:admin". However, when I check the application’s scopes, I don’t see any under “cloud_recording”, only “recording. Attached is a screenshot of permissions (which has historically been sufficient).
Any other potential sources? Is there an expected delay in propagation of configurations? I waited 10, 20 minutes before testing
Error? The full error message or issue you are running into, where applicable.
How To Reproduce
the steps to reproduce are fairly integrated with our platform, I can provide more details via DM if required
in general, I’ve approved this application App Marketplace and through my platform integration, I create a meeting, then enable recording in my meeting
after the meeting, I receive an email that my recordings are complete from Zoom and I can see them in my zoom cloud UI, but I do not receive a webhook
checked the application logs App Marketplace and double check webhooks are not present
Just as a follow up, I re-tested this flow this morning, just in case there was some expected delay with configurations being propagated.
I followed teh same steps as yesterday. I can confirm that I received a “recordings complete” email from Zoom and I can view the recordings in my zoom cloud. However, our application did not receive a zoom webhook event for recordings.complete, and I also do not see any webhooks in App Marketplace. I do see API logs for managing meetings, so can verify that other areas of this integration are working as expected.
I would not treat the missing cloud_recording:read:recording scopes as the root cause by itself. Zoom’s recording.completed use the newer granular scope names, but Zoom also says existing apps can keep using classic scopes, so a legacy app showing recording:* instead of cloud_recording:* can still be normal.
I’m not aware of a 10 to 20 minute propagation delay after deleting, re-adding, and validating the webhook URL. That said, Zoom tracks delivery attempts through Get webhook logs, and if the cloud recording is already visible in Zoom but there is still no recording.completed entry there, that points more toward a dispatch or subscription problem on Zoom’s side than your endpoint handler. One concrete check is to pull Get webhook logs for a meeting that definitely produced a cloud recording and confirm whether Zoom attempted any recording.completed delivery at all. If the logs stay empty, I’d ask Zoom support to verify the active subscription state for recording.completed on that specific app install using the app ID and a recent meeting ID.
If you need a fallback outside Zoom webhooks, you can alternatively use the Meeting Bot API to record and transcribe meetings.
Hi Amanda, thanks for jumping in! Yes I’ve verified that my recordings were generated but no webhooks are shown in the webhook logs for this application on teh zoom side (and I retested this morning in case there was any delay).
This suggests to me there is an issue in the zoom side with triggering webhooks. If any zoom support folks are taking a look, here is a sample meeting ID where a recording was expected qsReJVWLTuS+GujH3MsJ+w==
Hi Patric, we ended up having a few overlapping issues which we’ve since largely resolved:
our legacy app wasn’t handling the validation response and the webhook deprecation warning was being sent to hte app owner email, not the developer email that’s part of the app (email contact is still an open issue)
after this was fixed on our end to handle validation, the validation success state wouldn’t save in the app UI (no real resolution here, we ended up just replacing the webhook with a newer copy with same configs)
we deleted and recreated the webhook. It turns out that any changes to webhooks requires re-approval and publish of the app to be active. This wasn’t really documented anywhere before so zoom has agreed to update their documentation to reflect this. Note, when we were working on a fix for this, there wasn’t really any indication in the app portal UI that this is required either (ie my understanding is that the configurations you see as your “latest changes” in the app do not match the actual webhooks in prod until a newer app version is approved and published)
after this, our users had to re-authorize our zoom app to get the latest changes. We didn’t really have any notification about this either, we just learned this by talking with zoom support directly. It’s a little odd but FYI it may be treated as a re-authentication so the user won’t actually see the consent screen in the oauth flow (for us the permissions didn’t change anyways)
we were still seeing some discrepancies between the manually triggered validation webhook and the automatically scheduled ones but the main production webhook is back in order
