Description
I really enjoy working with Zoom’s API. It allowed me to develop a seamless system for customers to join our events without having to worry about registration or clicking a long URL in their email. It’s been a really successful integration between our custom portal and Zoom. But this latest API change really hosed my customers.
Error Message — “You have exceeded the daily rate limit ( $RateLimitValue ) of Webinar Batch Registration API requests permitted for ( {1} ) this particular registrant. You may resume these requests at GMT 00:00:00.”
$RateLimitValue — Maximum 3 requests per day.
One thing missing from the API is an endpoint to get a registrant’s info. This would be useful to see if a user has already registered. The only way to do it is to list all registrant’s and search through that array, but this becomes really tedious and inefficient when there are thousands of registrants. However, the Add Webinar Registrant endpoint smoothly handles duplicate registration attempts, it just returns the existing registrant if there already is one.
The new 3 requests per day limit on Add Webinar Registrant makes this really prohibitive. It means my customers cannot rejoin a webinar if they have multiple computer or connection issues. Why it so low, even for Business+ accounts? I had to scramble to create a performant workaround to this limit. Can we at least have 10 requests per day? Other endpoints allow 80 requests per second.
Error
{
"code": 429,
"message": "You have exceeded the daily rate limit (3) of Webinar Batch Registration API requests permitted for (email redacted) this particular registrant. You may resume these requests at GMT 00:00:00."
}
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
We’re seeing the exact same issue with the meetings version of these endpoints. Like chris.ota, we dual use the older API for both the CreateUpdate aspect and to do a Read for checking existence and getting existing data we may not have cached (e.g. join urls).
Would second the need for a higher rate limit in general, but also any best practice guidance on doing a pure read.
We are grateful for your thoughtful feedback and it is always welcome! Please be assured we will happily provide it to our product teams to be considered in our feature evaluation and design plans. If you would like to directly provide your use case to be considered for a future release, I recommend submitting your ideas to https://zoom.us/feed:
Thanks again for taking the time to provide your feedback and letting us know your frustration with the latest API change. I wanted to follow up to let you know I’m working with our Product and Engineering teams to identify how we can provide the best solution. I appreciate the details you’ve provided - the requirement to use the create registrant API in order to verify the registrant status is important to know. I see how the list registrants response can quickly get unworkably large at scale.
As to whether we can increase to something like 10 - I’m not sure yet. I’ll work with engineering on this and see what options there are. In the interim, an alternative approach you may consider to log all successful registrants information is with our Webhook APIs (i.e Meeting Registration has been created, Meeting Registration has been approved, ect). The join url will be delivered in the payload.
Additionally but importantly, I’m sorry you had to scramble to implement a fix to this. This is not the experience we want you to have to jump through. Thanks for taking the time to write this up. Your insights can help us readily improve by understanding exactly where to focus our time and energy, and how to prioritize requests to our product development team. Be assured that you have me to help address such concern as we aim high to give you the best Zoom experience possible.
Thanks for the response, @donte.zoom, and for bringing our concerns directly to the engineering team. Much appreciated.
One suggestion I have is to improve communication around significant and/or breaking changes to the API. Developers should have weeks of notice to update our integrations when rate limits are getting lowered. In this case, we started experiencing issues on a Saturday but the changelog wasn’t posted until the following Monday. Plus the new rate limit is still not reflected in documentation.
These new rate limits appear to have the common theme that email messages might be sent out to unregistered users, which would raise email deliverability concerns for recipients that might not have agreed to receive these communications. If that’s the case, is there an alternative approach where we can gain looser rate limits if we (1) opt out of the email sending, or (2) have our organization act as a relay to send email messages on behalf of Zoom, or (3) use only email addresses that are already registered with Zoom and have therefore agreed to receive email communications?
Our usage scenario is for the Add panelists endpoint for webinars, which is also affected by the rate limiting changes. We’ve noticed that the Zoom web site makes it optional to “Send invitation to all newly added panelists immediately” with a checkbox, but that option is not available in the API, which always sends invitations immediately. If our organization can take on the burden of sending email invitations instead of Zoom, that would let us customize the experience (so we can book these webinars far in advance but only send email messages when it is close to the begin date) and hopefully reduce the email deliverability concerns that might have originally prompted these rate limiting changes. Our webinar panelists are frequently the same people from instance to instance, and we can work with them to register with Zoom in advance so they can agree to receive email communications.
I would like to point out that this change to rate limits effectively disables ability to implement own registration forms. This was previously recommended to developers by Zoom staff.
You’re right, we should provide proactive communication for changes like this. We are going to use this as an example on how and where we can improve. Many thanks for providing us your valuable feedback, it is the driving force to helping us achieve our mission.
Thank you for sharing your usage scenario. Have you considered setting the “panelists_invitation_email_notification” flag to false when creating a webinar ? This should prevent those email notifications from being sent out to panelist immediately :
Thanks for the advice on the panelists_invitation_email_notification flag; this helps with the user experience, but we are still running up against the new rate limiting rules. Our organization tends to have around 5 webinars with associated panelists scheduled on a single UTC day, which is more than the 3 allowed by rate limiting, so we’d still like to explore options that would loosen the rate limits.
Thank you for reply, @MultiplayerSession ! To clarify, the API limitation error only occurs when the SAME user is registered to the SAME meeting/webinar more than 3 times. Please make sure not to re-register users that are already registered.
Thanks for the clarification; that addresses our rate limiting concerns. Please consider clarifying this aspect in the update notes, since the "$RateLimitValue — Maximum X requests per day…" phrasing is used in both the account-wide Create users API and per-recipient-per-meeting other API limits.
We scrambled and made changes to cache the initial results which covers most of our issues, though best practice on checking a particular user efficiently will be great for various edge cases.
Per others in the thread, our biggest feedback at this point is mostly around communication of these changes that may (or may not!) have unintended consequences. I’m not sure what we should be tracking on our engineering side so we can be more proactive in adopting changes vs reacting after the fact.
Thank you for your feedback regarding communication of these changes that may (or may not!) have unintended consequences. What you shared will help us to improve and better serve the developer community.
