Recording.completed event fired twice

Continuosly receiving “recording.completed” event twice for the same meeting. The delay between events is exactly 5mins.
All other events has no such problems. And I’m pretty sure that my handler responses with 200 status code in less then 30seconds.
Does anyone know where problem could be?

Yes, I’m getting the same thing! I had been running a lambda function on Netlify using this webhook and it had been working perfectly for weeks. The first time this issue started happening was on July 14 and the only thing I had changed in my codebase recently was adding an email address to a whitelist.

I switched my app over to a webhook-only app, because the version I had setup wasn’t giving me any Zoom logs. I started monitoring the Zoom call logs. I thought maybe the response wasn’t coming back fast enough from my function and so Zoom was firing off a retry request. But the logs show that the success response time is about 3-5 seconds, which seems like it should be fine.

The other odd thing is that the second webhook request always fires about 5 minutes after the first one. If it was a retry request, I would expect it to fire again immediately.

Is anyone else having this issue or does anyone have more ideas about what could be going on? I’m wondering if something changed in the Zoom codebase around this time to cause a bug.

After a little more looking into the logs, I think the second request actually is a retry request. I found this in the headers:

"X-Zoom-Retry-Reason": "hystrix time out",
"X-Zoom-Retry-Num": "1",
"x-zm-trackingid": null,

The thing I don’t understand is how I got a success response back in less than 5 seconds, but the function still timed out. I think I’m going to have to look into the Netlify side of things to debug this.

@juchkov11, are you using Netlify lambda as well? Just curious if we’re having the same issue or something different.

Hi, no. In my case handler is running on dedicated server. So, I think problem is not depending on environment. I will try to respond with 204 status code and see how it goes.

Hey @juchkov11 and @drosentrater,

I’d suspect this might be a network issue that our end didn’t receive the ack, thus we sent it twice.

Can you direct message me with your account id and meeting id so I can look into this further?


Good morning, @tommy!
It seems I have no privileges to send direct messages. (probably because I am new forum user). Could you please suggest another way to communicate?

@tommy I’m in the same boat. I don’t think I have spent enough time on the message board to be able to send direct messages yet. Perhaps you can message me? Otherwise, I’ll spend some more time on the forum until I get messaging privileges.

@drosentrater, @juchkov11,

Just private messaged both of you.

We’ve confirmed this was triggered by retry. However, we are still researching if feasible for us to further improve our current network error detection logic. For now, please disregard the 2nd callback message.


To fix this, try sending a 200 response back within a few seconds (1 second if possible). If Zoom does not get the 200 response, it initiates retry logic after 5 mins.

Here is an example of how to send a 200 response after receiving a webhook event in Node.js / Express'/webhook', async function (req, res) {
  // need to respond within 1 second with a 200 or else Zoom thinks webhook did not work and will retry.
  // your app logic here


We have updated our docs with how to respond to webhooks.