Inconsistent Screen Sharing Webhooks

We have been using the meeting.sharing_started and meeting.sharing_ended webhooks to track screen sharing for our users. Every once in a while, we get a bunch of meeting.sharing_started webhooks when we are only expecting one. This seems to only be happening for one user currently.

Here are some logs of the webhook payloads we received. Starting from the bottom, you can see the meeting was created and started, then Brady and Caleb successfully start and end sharing their screen. But then, Brady starts sharing his screen again and we get four meeting.sharing_started webhooks instead of one. At first I thought we may be creating dups on our end, but I think these extras were sent from zoom because they have different event_ts fields in the payload.

Additional context
I’m happy to send more information over DM

Hey @ryan.buchmayer,

Thanks for reaching out about this, and happy to help.

As a first step, can I kindly ask what app type you’re subscribed to these webhook events under (Webhook Only, JWT, OAuth, etc.)? Additionally, if you have more than 1 app under your account, can you double check that you haven’t subscribed to the same event under any of your other apps?

A few other things to confirm as well:

  • Were there any connection issues during this meeting that you know of?
  • Do you know how the user was sharing? (e.g., Desktop, Application Only, Entire Screen, etc.)

Let me know when you have a chance! Thanks,

Hi Will, thanks for the helpful response. We are using an OAuth user-level app. We do have multiple apps that are subscribed to the same events, however, the Event notification endpoint URLs are different across the apps, so the event webhooks are not being sent to the same place.

There doesn’t appear to be any connections issues during the meeting, and the user was sharing their entire screen. This appears to be a rare edge case since we have only seen it happen twice, both times with the same user.

We were able to implement a workaround the first time we saw this issue, but the second time this happened was a little different. We got a bunch of duplicate meeting.sharing_started webhooks like the first time, but the final few webhooks seemed to have some malformed data. I’ve blacked out some of the noise/sensitive info, but starting from the bottom, the first four webhooks look good, then we get the flood of meeting.sharing_started webhooks (which all have different date_time and event_ts fields in their payloads). Finally the last three webhooks are missing the participant['id'] field and contain a bunch of \u0000 characters, which I think is null in unicode

Any ideas why we might be getting this malformed data? I am curious if it has something to do with the specific user, since it was the same user both times.


Hey @ryan.buchmayer,

Thank you for confirming these details.

Can you please share the full raw webhook payloads for a recent example of these duplicate events, including the event_ts fields? Please share this directly with us at so that we can take a closer look.


Thanks @will.zoom! I’ve sent them your way.

Thanks Ryan, we’ve received your email and will be in touch shortly!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.