I’m registering users for a webinar via API, and i’m getting intermittent 429 errors stating
“You have exceeded the daily rate limit of (3) for Add a webinar registrant API requests for the registrant (user@example.com). You can resume these API requests at GMT 00:00:00.”
I have confirmed the user is NOT registered for the webinar.
Why am I getting this error, and how can I avoid it?
i’m having the same issue that was mentioned here Error code 429 : exceeded the daily rate limit of (3) - #3 by MultiplayerSession and was never resolved, as discussed by @guilherme.capile and @avinash.moharil and @gianni.zoom
I am NOT posting the same registrant to the same webinar.
I AM posting the same registrant to a dozen DIFFERENT webinars.
This is not a limitation that’s documented, and if it is a hidden limitation, I will need more guidance as to best practice for handling this.
Here is a small sample of the x-zm-trackingid values for these responses:
Why am I getting this error
HTTP 429 indicates that you have exceeded a rate limit imposed by the Zoom API. Typically, this happens when you issue too many HTTP requests to a given endpoint in a short period of time (the Zoom API sometimes limits the number of requests you can issue per second, sometimes it’s per hour, per day, etc.). But there are a few more rules that are sometimes specific to a given endpoint.
how can I avoid it?
You can avoid this error by reducing the number of requests you issue to a Zoom endpoint in a period of time. For example, don’t issue a gazilion requests in a tight for each loop.
Another strategy you could use is to inspect the headers of the HTTP 429 response and look for specific values that will help you determine how long you should wait before reissuing your request.
This is explained in more details in this article: Rate limits
Edit: also, you are more specifically experiencing this problem when registering people to webinars. As the error message states, there’s a daily cap on the number of times you can register someone for a webinar (any webinar that is). Therefore I suspect that you are experiencing this problem because you tried to register “user@example.com” for Webinar1 as well as Webinar2 as well as Webinar3 as well as… and so on. I’m not 100% certain but I believe this rule also applies to instances of a recurring webinar which means that you would get this same error if you tried to register someone for the January instance of a monthly recurring webinar, as well as the February instance, as well as the March instance, as well as the April instance, and so forth.
Edit 2: I re-read your second post and noticed you said I AM posting the same registrant to a dozen DIFFERENT webinars. This is the root of the problem: there’s a “3 registrations per day for a given person” limit and you tried to register this person 12 times.
Edit 3: to add to the confusion I think the verbiage of documentation on this topic is misleading.
3 requests per day (UTC) for the same registrant in the same meeting/webinar
This clearly says “same meeting/webinar” but I think it’s intended to say something along these lines: “3 requests per day for the same registrant to any meeting/webinar” (Zoom staff please correct me if I’m wrong). As the rate limit rule is currently worded, I can totally see why you would think you can register someone to 12 different webinars in a loop but I don’t think the documentation says what it intended to say, hence the confusion.
Edit 4: the “Rate Limit” documentation I linked previously used to describe the headers you can expect in a HTTP 429 response but I just realized this information is no longer in the doc. My code has been relying on these headers for years so, as far as I know, they are still present. I have no idea why this information has been removed from the doc. An oversight maybe?
Thanks for all this info. Your suggestions confirm what I have been surmising are the issues with missing or inaccurate documentation.
Another strategy you could use is to inspect the headers of the HTTP 429 response and look for specific values that will help you determine how long you should wait before reissuing your request.
You’re referring to the retry-after header, i assume?
I have also been curious about this, but was hopeful that I wouldn’t have to refactor my app against these under-documented limits. Sounds like I’ll need to dig into that after all. 
Any ideas about the intermittent 401 and 404 errors i posted?
I have to believe they’re related.
The documentation from a few years ago mentioned 5 different headers: X-RateLimit-Category, X-RateLimit-Type, X-RateLimit-Limit, X-RateLimit-Remaining and Retry-After . The ‘Category’, ‘Limit’ and ‘Remaining’ headers are informative but, in my opinion, not useful for the purpose of deciding how long to wait before reissuing a request. My logic relies only on the other two headers.
When the response from the Zoom API is HTTP 429, my logic is something like this:
Is it possible that you use the Webinars UUID on the querystring and you don’t properly double encode this value?
In the vast majority of cases, it doesn’t make a difference whether you encode this value or not because it doesn’t contain any special characters to begin with. But there’s a small percentage of cases where the UUID contains a character that requires encoding (such as a slash for example). It’s been a long time since I dealt with this problem so it’s not fresh in my memory, but I vaguely remember that the error message is something like “Meeting not found” or “Webinar not found” when you don’t encode a UUID that contains one or more slashes.
The fact that UUID sometimes need to be encoded but most of the time doesn’t, can reasonably lead someone to conclude that the error is intermittent but the truth is that you consistently get an error when the UUID contains a slash.
Is it possible that you use the Webinars UUID on the querystring and you don’t properly double encode this value?
Unfortunately, this is not the case for me.
300 registrants were posted successfully, 75 others are getting the 404 error.
Same API endpoint URL for all of them.
Makes zero sense.
Guess I’ll wait for followup from Zoom support, thank you.
Hi @Aaron5
Thanks @desautelsj for jumping in here and for you valuable help!!!
I have created an Engineering ticket to look into this since I am not able to reproduce this on my end.
The updates will be posted in this thread
Here are the most recent tracking ids for the 429 errors when registering to Webinar ID: 881 0377 2725
v=2.0;clid=us06;rid=WEB_a83d65a965da85c246ec78849e65213a
v=2.0;clid=us06;rid=WEB_007239dc56f53bb943e6653b1c17265a
v=2.0;clid=us06;rid=WEB_9452db53986d5f1012f383cf86fec7fc
v=2.0;clid=us06;rid=WEB_b7ddc8521996268c5d6fd72ce58bbedb
This webinar has 405 registrants, and a capacity of 3000.
At least 300 of those registrants were created successfully using this same endpoint, including dozens in the past 24 hours.
I have confirmed that none of the emails attached to any of these requests is registered to this webinar.
@Aaron5 I’ve checked those tracking ID, they have the same error. The error is due to >3 registrations (add/update) request for the same user for the same webinar within the same day.
@Aaron5 I’ve looked deeper into this.
When a user’s webinar registration is rate limited, there is no backoff strategy and the API call stills continue to call. Compounding by number of users, these failures will unnecessary utilize the API call limit from an account level.
There are also calls to register a user to a webinar after it has ended.
Do consider looking at batch registration as well Zoom Meeting API - API - Zoom Developer Docs
Thank you for looking into it.
It seems that this is a symptom of the other issue i’ve posted, Webinar registration: 404 not found: error code 1001 User does not exist - #11 by Aaron5, where the user registration fails with an inexplicable “404 User does not exist”
Even though the user is not registered, there were 3 failed registration attempts (which happened to yield a 404 response). Those 3 attempts count against the daily quota, and all requests yield the 429 response.
I think this thread can be resolved, and I’ll look forward to a response on Webinar registration: 404 not found: error code 1001 User does not exist - #11 by Aaron5
Batch registration would be great, but will not work for this use case, because I need to post several values other than email and name.
Batch registration parameters are limited to email, first and last name.