429 error for user who is not registered

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:

  • v=2.0;clid=us06;rid=WEB_c2dbf35f925abc1348b866f06e637189
  • v=2.0;clid=us06;rid=WEB_a31f39da8ee4377056c8866a98c99c05
  • v=2.0;clid=us06;rid=WEB_20b81f58f79b5def3d79320c04d843b7
  • v=2.0;clid=us06;rid=WEB_c63605edf87e933b3e8f0dfdd6ebef17
  • v=2.0;clid=us06;rid=WEB_99ac9dac6051ff54ac01f65bd35dbd8d

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?