I was told this was identified as a bug and the team was working on addressing it, but we are still experiencing this issue today, on an almost daily basis.
I’ve verified that we are not storing duplicates on our end because each webhook payload contains a different event_ts
Here’s an example of 7 meeting.sharing_started webhooks coming in, all for the same user.
Hi @ryan.buchmayer
Thanks for reaching out to the Zoom Developer Forum!
I am happy to help here and sorry for the late reply.
Can you confirm you are still getting these duplicates when receiving meeting.sharing_started and meeting.sharing_ended events?
Yes, we are still getting these basically daily. I don’t think we are recording duplicates on our end because each affected webhook has a slightly different event_ts, which comes from Zoom.
I wonder if this is affecting our Zoom app only, or if it is a widespread issue?
I was able to reproduce my issue, and now I’m wondering if it’s a feature or a bug. Is this expected or documented anywhere?
Steps to reproduce:
Start screen sharing
Pause screen sharing
Resume screen sharing
Result:
An initial meeting.sharing_started event (when the user initially starts sharing).
Another meeting.sharing_started event (when the user pauses sharing).
Two more meeting.sharing_started events with very close event_ts (when the user resumes sharing).
Would it make sense to either have new webhooks for meeting.sharing_paused and meeting.sharing_resumed, or not fire the meeting.sharing_started event when sharing is paused/resumed?