Feedback for an approach on handling malfunctioning webhooks

Our app uses webhooks to keep local copies of Zoom meetings taking place under our account. For example:

  • meeting.created → create the meeting in our DB
  • meeting.participant_joined → create the participant in the DB
  • meeting.started → set the start time of the meeting
  • meeting.ended → set the meeting as ended, etc

One common issue we see is that sometimes webhooks arrive in the wrong order or sometimes they don’t arrive at all, this makes our job difficult.

In an attempt to make our lives easier, we’ve been thinking about only listening to the meeting.ended webhook and then simply calling the Zoom API to get all of the information for that meeting and information for that meeting’s participants.

I have two questions:

  1. Does this approach seem reasonable to Zoom?
  2. Are there any constraints I need to be aware of being doing this? (For example, maybe it’s the case that after the meeting has ended, it takes a while for the meeting to appear in the Zoom API response. Etc.)

Hi @ogen.odisho_zp ,

I agree, the events should be delivered synchronously, but in very small number of cases due to multiple reasons they may be delivered asynchronously.

Recently we deployed a fix that would enable to handle us the delivery of webhooks better, and since then we havent received any complaints about non delivery, But if you are still facing this, please DM me the meetings IDs (after sept 2) and I will be happy to take a look.


Hi @ojus.zoom , thank you for the reply.

I currently don’t have any problematic Meeting IDs - I am trying to be proactive in making the application resilient against misbehaving Zoom webhooks.

I understand that improvements to the delivery of webhooks have been made and that is greatly appreciately, but we still want to have a contingency in place to synchronize the meetings in our DBs with the meetings on Zoom’s servers.