Zoom Webhook: some meeting events not firing

API Endpoint(s) and/or Zoom API Event(s)
meeting.participant_admitted and meeting.participant_joined events not firing when participants join a meeting after being released from the waiting room.

Description
I am creating an integration between Zoom and our web platform. I have been able to successfully create meetings via the REST API and register participants for the meetings. Our meetings are always set to have a waiting room, with all participants, except the host, being sent to the waiting room. When a participant joins the waiting room, or is admitted to the meeting, neither of the relevant web hooks (meeting.participant_joined_waiting_room and meeting.participant_admitted) are firing. My web app is successfully receiving web hooks for other events, such as the endpoint.url_validation , meeting.started, meeting.ended and recording.completed events. I have double-checked that the appropriate meeting events are enabled for our app, but they aren’t firing for some reason. What am I missing?

I have added all meeting scopes to the Zoom app, so I wouldn’t expect that to be a problem. We are on the Zoom Business plan and I am using an admin account to create up the Zoom API app.

Error?
To be clear, there are no error messages happening and when I check in the Events Dashboard for our Zoom app, the desired participant events aren’t even listed, so it appears they aren’t firing at all.

One other thing, participants are all external to our org, so not users on our Zoom account. They all have to register for the meeting (which is done via the REST API and is working fine). Does the fact that participants are all external and don’t have Zoom accounts have any bearing on whether or not the meeting.participant_* web hooks are fired?

Our Zoom app is Server-to-Server OAuth, does this affect the ability to access meeting.particpant_* web hooks? Would changing to a user authenticated app resolve the issue?

Any advice on what to try, or what I might have missed would be appreciated!

Many thanks

Hi @Causeway , yes this seems to be the case now according to the documentation, but this wasn’t always so:

A meeting attendee is a meeting participant or the host. The meeting host must be a user in your account or a user in any other accounts that have installed your webhook-enabled app.

Are you able to get the participant info from this endpoint get/past_meetings/{meetingId}/participants using your S2S app credentials?

If so, please let me know and share the zm-tracking-id from the response header and I will go back to the Meeting engineering team to call out the incongruities.

Hi Gianni

Many thanks for the suggestion.

I can confirm that this returns all the meeting participants, including those who are not users on our account.

The zm-tracking-id header for this request was: v=2.0;clid=us06;rid=WEB_60429934a04d5b860c449bd5188ad8ca

Just to confirm, all our meeting hosts are users on our account, and all other participants are external people who do not necessarily have a Zoom account, but have all been through a registration process for the meeting via our S2S app.

Please let me know if you need anything else and thanks again.

Hi @gianni.zoom

Just checking that you’ve seen my reply and wondering if you need anything else from me to be investigate this.

Thanks!

Hi @Causeway , we are looking into this and waiting for meeting API service engineering team to get back to me (ZSEE-195127).

Hi @Causeway , they said waiting room was not enabled for the host:

Can you please confirm and share how you were able to have a waiting room if this is not selected? This needs to be selected for you to receive those webhooks, but if you enabled waiting room programmatically with the creation of the meeting, and you saw the waiting room, I want to investigate this further. The UI and API should have parity to avoid confusion. Can you please confirm and re-test this please?

Hi @gianni.zoom

The meeting for that test was created programmatically using the API and definitely had a waiting room.

I’ve also noticed that webhooks are now coming through as expected, so I don’t know if anything has changed on your end, or if something else was going on that prevented us from receiving them before, but we are definitely receiving them now.