You have exceeded the daily rate limit (3) of Meeting Batch Registration API requests Zoom Error

You have exceeded the daily rate limit (3) of Meeting Batch Registration Error

Description
when I assign registrants to the several meetings I’m getting this kind of error
“You have exceeded the daily rate limit (3) of Meeting Batch Registration API requests permitted for (xxxxx@gmail.com) this particular registrant. You may resume these requests at GMT 00:00:00.”

How we can assign more than 3 times per day?

Error
Can’t assign registrants to meetings

Which Endpoint/s?

/meetings/{meetingId}/registrants

1 Like

Hi @sachinnadeesh ,

Thanks for your inquiry. We are making adjustments to the rate limits for this particular endpoint. Here’s the changelog for more details: https://marketplace.zoom.us/docs/changelog#publications/api-rate-limit-enhancements-september-20-2021-1 :slight_smile:

Thank you,
Gianni

Hello,
The changelog post shows the same response messages generated for both 429 responses on ‘Add meeting registrant’ and for ‘Perform batch registration’. We have received this ambiguous message. We are calling the registrants endpoint but receiving a response regarding batch registrant.

Currently the changelog mentions a $RateLimitValue of 3 requests per day to Batch Registration API. I was unable to exceed this limit in testing, using postman/curl. However, in production we have run into this issue.

1.) Are the current rate limits set the same for both?

2.) What is the rate limit for “Add meeting registrant”?

3.) What is the scope of the rate limiting(e.g. per user, per account, per ip address, across webinars and meetings )?

4.) The create users API shows multiple levels for Free, Pro and Business+, do these other endpoints have the same tiered structure?

1 Like

Is there any method for increase these limits?

Hi Gianni!

In the blog post, it is confusing as it suggests that the rate limit of 3 applies to both the single object endpoint ( POST /v2/meetings/{meetingId}/registrants a previously “light” api) and the batch endpoint (POST /v2/meetings/{meetingId}/batch_registrants a “heavy”) for Meeting and Webinar Registration APIs. Is that correctly applied for both single and batch endpoints?

In our production implementation where we add single registrants (/registrants), we are seeing the Batch error message: “You have exceeded the daily rate limit ( $RateLimitValue ) of Meeting Batch Registration API requests permitted for ( {1} ) this particular registrant. You may resume these requests at GMT 00:00:00.”

This change has broken our implementation. 3 is very low for adding single registrants in a 24 hour period.

Can the devsupport team verify that both endpoints are now rate limited to a daily quantity of 3? If that is correct, we’ll need to rewrite our implementation as we depended on the requests per minute rate limiting in place before today.

Thanks,
-Chris

@David-Gabriel @sachinnadeesh @chaupt_swoogo

Yes, the Add a Meeting Registrant and Batch Meeting Registrant API both have the same rate limit.

When it comes to the Add a Meeting Registrant rate limit, this only applies when making a request with the same registrant and meeting more than 3 times a day. You can add multiple unique registrants or add one registrant to many meetings just as before.

Further, you should be able to use the occurrence_ids field to add a registrant to multiple occurrences of a webinar/meeting with a single API call. You can then make further calls

Yes, but it is a lengthy process that involves our product management approval. Often, hitting the rate limits is a sign of an anti-pattern.

Let me know if that helps.

Thanks,
Max

I’m having the same problem when trying to create the participant for the first time in the meeting, it wasn’t created and when creating for the first time it’s giving limit error. This problem started to give today a few hours ago, it looks very much like a bug


Captura de tela de 2021-09-24 17-17-23

Exception: Request failed for https://api.zoom.us returned code 429. Truncated server response: {“code”:429,“message”:"You have exceeded the daily rate limit (3) of Meeting Batch Registration API requests permitted for (mani.zel1@gmail.com) th… (use muteHttpExceptions option to examine full response)

I am trying to add registrant for recurrence meeting of about 12 instances with occurrence_ids. But still I am able to register only for 3 occurrences. This is really stopping us. How do we proceed. we dont want to change meeting ids.

We were able to register even few days before. why this restrictions?

Is there a way I can add registrant for same recurrence meeting(ours is 12 - 15 occurrence) with occurrence ids more than 3?

1 Like

I’m having the same issue with occurrence_ids not being properly saved, even when I use a comma-separated list of occurrence_ids still it doesn’t work. This is only after the rate limit is added to this endpoint.

{
“type”: “object”,
“properties”: {
“occurrence_ids”: {
“type”: “string”,
“description”: “Occurrence IDs. You can find these with the meeting get API. Multiple values separated by comma.”
}
},
“required”:
}

@pedrosilvaigor @heshanlk @psistream01

Thanks for following up on this. I tested this on my end and wasn’t seeing a 429 error when using more than 3 occurrence IDs. Are you able to share steps I can use to reproduce this? Further, what registration_type are you using when you see this?

@MaxM I have the registration_type set to 2 and I’m passing occurrence_ids as comma separated list so the URL looks like

POST /meetings/[MEETING ID]/registrants?occurrence_ids=[ID],[ID2],[ID3] etc, also I only see one response coming back all the time.

Hey @heshanlk,

My apologies for the delay here, please submit a ticket and include a link to this thread. In that message, please also include the App Name, App Owner Email, and steps to reproduce the issue.

You can submit a ticket by navigating to our Developer Support Center.

I’ll investigate further in that ticket.

Thanks,
Max

We are encountering this issue trying to register someone for multiple different webinars.

We register them on webinar 1, which is a succes, then register them on webinar 2, which is a success. Then register them on webinar 3, which is a success, but from that point forward we can no longer register that email address on any further webinars.

This is extremely broken if that is how it works, your now saying we can’t register the same email address for more then 3 webinars in a 24 hour time period?

UPDATE: Tested this and it appears that you can submit multiple creates, in the past this would have just returned the previous submissions data and you’d go on with your business, so now we make additional API calls to fetch pending and approved people.

I’ve been having this issue for about a month now. I’ve done everything I can to optimize and use the API as little as I can and I’m still busting the limit for unknown reasons. Something is definitely up with the API. It’s ridiculous, it broke our system and the change was made without warning.

Hey @pierrealexislebrun and @xantari,

I’ve seen with some developers that the Add Webinar Registrant API is being used each time the user fetches their join URL. I would first make sure there isn’t any pattern such as that in the application.

In such cases, you can either store the join URL or use the List Webinar Registrants API to get the join URL.

If that’s not helpful, please provide steps to reproduce the issues you’re encountering and I’ll investigate further

Thanks,
Max

@MaxM
Is there a way you propose upserting registration data that doesn’t hit the max 3 update list?

In the past we would use the Add Meeting Registrant endpoint, as it seemed to do an “Upsert” of data. We are feeding these in from an external system. Users can change things in that external system which then makes us upsert those changes into the custom_questions array in this endpoint:

It looks like we can only do that 3 times now. If our end users change something in this external system is there an alternative way we have now of upserting this new information to you if these users try to update their data 4 times or more?

Also, what about updating their name or email?