Using this template helps us debug your issues more effectively
Description
I have created a Zoom integration for registrants that has been working well for a few years. Now a certain registrant is seemingly successfully added to the webinar. A subsequent call to retrieve data for the registration fails with …
Error
This registrant does not exist: oJmpgKTWT2yoKQTuJXjEBA.
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
Which Endpoint/s?
See title
How To Reproduce (If applicable)
Steps to reproduce the behavior:
POST to webinars/REDACTED/registrants
payload: {“email”:“REDACTED”,“first_name”:“REDACTED”,“last_name”:“REDACTED”}
Returns registrantID REDACTED (cannot reproduce anymore, daily API limit of 3 calls reached)
Subsequent call
GET to webinars/REDACTED/registrants/REDACTED
returns error “This registrant does not exist”.
The registrant is also not visible in the web interface.
Additional context
Same e-mail-address is also signed up as a panelist for the same webinar. Cause of the problem?
Matter is time-sensitive as you can see (webinar starts Monday, API integration failures cause serious trouble with our front-end)
So evidence is mounting that trying to register someone who already has panelist access to the same webinar does return a link but trying to use that link will fail as the registration just silently gets dropped.
What’s worse, there is evidence of GDPR violation again as removing a panelist leads to the same behavior (trying to register a person with the same e-mail-address as a registrant fails silently while returning an invalid link). This means that removing a panelist does not actually wipe any record of their e-mail-address just like the behavior with registrants that I have noted a few years ago.
I have worked around the issue for the upcoming webinar by using different pseudo e-mail-addresses for panelist registrations from now on as opposed to regular registrants. I have stopped sending Zoom actual e-mail-addresses of users early on for two reasons: One is another bug that makes it impossible to prevent Zoom from sending emails when a webinar registration is cancelled. The other is our intention to adhere to GDPR which means that we need to be able to completely wipe/anonymize a user’s data on your platform once they choose not to participate or ask us to remove their data. I have learned that Zoom will allow me to “cancel” a registration but will not remove a user’s data (including their e-mail-address) which would mean we couldn’t adhere to privacy standards using Zoom.
I have now learned that the same behavior applies to panelists, I cannot (or at least have found no way to) delete a once-entered panelist e-mail address from your system and this fact means that bugs relating to having an address in the system cannot be remedied by deleting a registration.
Thus, unfortunately for this event, we still cannot add regular registrations for people who are also panelists without explicitly altering their e-mail-addresses sent to the registration endpoint.
I’m pressed for time and since I have worked around the issue for now, I cannot debug it again right now to find the IDs you have redacted in my post in order to create that support ticket you asked for. I may be able to do so after the event.
The general points in this issue seem to be valid regardless of any specific webinar ID though. Here are the main points:
It seems Zoom does not allow for the same person to be registered as a panelist as well as a registrant to the same Webinar. That is fair and may well be intentional. If so, however, attempting to add a registrant through the API when there is a panelist with the same e-mail-address in the same webinar should result in a FAILURE reply by the endpoint, not return a success message including a participation URL that will not work.
There still seems to be no way to properly and thoroughly delete an e-mail-address from Zoom’s database once it has been entered as a panelist or registrant. The API and web interface will make it seem like they have been successfully deleted as expected by me as a user but they actually persist in the database as can be inferred by the phenomena mentioned above. In my understanding this is a privacy concern as GDPR postulates for users to be able to delete their data.
