WebHook Duplicate Events - meeting.participant_jbh_waiting

API and Webhooks
1

Description
Users who join the waiting room prior to a meeting having started seem to frequently be generating duplicate meeting.participant_jbh_waiting events via the Webhook. The duplicate events are usually 30-35 seconds apart from each other.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
This message is coming from a webhook tied to event type meeting.participant_jbh_waiting.

Sample JSON, original event:
{
“event”: “meeting.participant_jbh_waiting”,
“payload”: {
“account_id”: “I-sR4500TQW8Jy5oLpkSRQ”,
“object”: {
“duration”: 720,
“timezone”: “America/Phoenix”,
“topic”: “Virtual Visit on 4/27 for Serenity Cruz at Phoenix Children’s Hospital”,
“id”: “***********”,
“type”: 2,
“uuid”: “cAYr5OmXQPKjc1R7sw0DIA==”,
“host_id”: “B3LjVDN5Q7eiscqK8Nb3Tw”,
“participant”: {
“user_name”: “”
}
}
}
}

Sample JSON, sent 30 seconds later
{
“event”: “meeting.participant_jbh_waiting”,
“payload”: {
“account_id”: “I-sR4500TQW8Jy5oLpkSRQ”,
“object”: {
“duration”: 720,
“timezone”: “America/Phoenix”,
“topic”: “Virtual Visit on 4/27 for Serenity Cruz at Phoenix Children’s Hospital”,
“id”: “***********”,
“type”: 2,
“uuid”: “cAYr5OmXQPKjc1R7sw0DIA==”,
“host_id”: “B3LjVDN5Q7eiscqK8Nb3Tw”,
“participant”: {
“user_name”: “”
}
}
}
}

*This post has been edited to remove any meeting / webinar IDs

2

Bump… does anybody from Zoom have any explanation for this?

3

Hey @jmauck,

This most likely is happening because you are not sending a 200 OK response, so Zoom attempts to retry sending the Webhook.

Double check you are sending a 200 OK response after you receive a webhook event on your server…

Thanks,
Tommy

4

Hi @tommy,

We’ve verified that the only response we’re ever returning via the webhook endpoint is a 200 OK (even if there’s an error parsing the JSON).

What’s odd is that this only seems to be happening with meeting.participant_jbh_waiting events. No other event type is doing this. They are all spaced out 30-35 seconds from each other.

We ended up putting some code in place that compares the incoming JSON to anything that’s already been logged and are skipping the logging if it’s a duplicate, but that comes with some overhead.

If you’d like a few examples of duplicates from this morning, here are some meeting IDs:
*********** (sent 15 times today)
*********** (sent 63 times today)

~Justin

*This post has been edited to remove any meeting / webinar IDs

5

Thanks @jmauck,

We are investigating this and will get back to you. (ZOOM-160068)

-Tommy

6

Hey @jmauck,

I see the user_name value is blank in your JSON. Did the user_name not come through too?

Thanks,
Tommy

7

Hi @tommy

It’s seems relatively common for the user_name to come across without a value. In the past hour, 37 of the 150 events we logged with a status of meeting.participant_jbh_waiting had a blank participant { user_name }.

~Justin

8

Hey @jmauck,

The username could not come through if the user joined the meeting without being signed in to the Zoom account / app.

Thanks,
Tommy

9

Hey @jmauck,

Engineering needs more details on how the user is joining the meeting. Are they using the join link? What device and version are they using?

Thanks,
Tommy

10

In these cases, the user is being redirected to the Join_URL link. We’re not exactly clear what device(s) the users might be using, it’s probably a mixture of mobile devices and desktop devices. These are end-users (public, not associated with our account) joining meetings that we’ve set up, configured to place them into the waiting room if the meeting hasn’t started yet.

I personally have been unable to replicate the missing username - when I join the same link from my phone, it appears to pass my phone’s name into the WebHook data. I’m using iOS.

11

Hey @jmauck,

It seems these users used the Windows App when joining, they must have not entered their name when joining the meeting.

Thanks,
Tommy