Description
Zoom API “List Webinar Registrants” returns based on status “approved”,“pending” or “denied”.
“denied” means EITHER a pending registrant was denied, or an approved registrant was canceled by a webinar admin.
If a user cancels their own registration, the registrant is removed entirely from the webinar, and the user is free to re-register.
The problem is that there is only one webhook for both events: “Webinar Registration Cancelled”.
This webhook sends identical data for either action, even though from Zoom’s perspective (and my app’s perspective) the actions are handled very differently.
To keep data in sync with our own system and determine how to treat our user, we need to know which type of cancelation happened.
The only way to do this that I can see is to do an additional Zoom API “Get a Webinar Registrant” call to determine which type of cancelation happened. This seems very klugey and inefficient.
Error
Webhooks do not distinguish between user registrant cancelations and admin registrant cancelations.
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT/Webhook
Which Endpoint/s?
Webhook: webinar.registration_cancelled
How To Reproduce (If applicable)
Setup webinar.registration_cancelled handler, test user-driven cancel as well as an admin cancel (via Zoom UI).
Thanks for raising this use case with us—you make a great point.
While the webhook doesn’t distinguish between cancelation types at the moment, I’ve reached out to our team to see if this is something we might be able to add in the future. (ZOOM-211588).
Thanks @will.zoom.
In a similar vein, there seems to be no way for the Zoom API to mimic a user cancellation.
“PUT # /webinars/{webinarId}/registrants/status” allows for “cancel”, but this is the same as an admin cancel, which puts the user into a “denied” status.
We want our users to be able to cancel their own registration and re-register, similarly to how they can via links from zoom emails.
Currently this seems impossible via the Zoom API.
Also, to make this feature set complete, " GET # /webinars/{webinarId}/registrants" should have a query param status of “user_cancelled” or just “cancelled”, which will list users who registered but canceled themselves.
Doing a " GET # /webinars/{webinarId}/registrants/{registrantId}" on users in a user-canceled state show them with a status of “all”, which is not documented anywhere, and there is no way to list users in this state.
For some potential workarounds, have you considered using the “operator/operator_id” fields to identify whether or not a registration was canceled by self (the registrant), or if the registrant was removed?:
