100 meetings/day limit

We are a coaching company which offers coaching classes that are conducted over zoom. As part of our administration, we have a system which assigns coaches to our classes, by creating a zoom meeting and then assigning the coach as the host for the meeting.

The way that we have implemented this is that we use a single account to create a zoom meeting and assign the coach as the host. Most of the time, this system works OK, but on some days, we try to create and assign more than 100 meetings and coaches in a single day, which means we hit on the limitation as described here:

Because the assignment is centralized (that is, our administrators assign the coaches to particular classes based on availability, history teaching similar classes, etc.) the coaches can’t assign themselves so there’s no way to get around using a centralized account like how are are doing it now. We also do sometimes change the data after the fact (for example, to assign a different coach or set another coach as a backup coach using the alternative_host setting).

We can manage around this by (for example) keeping ourselves limited to just 100 classes per one day, and then setting the remainder on the following day, but this method introduces a manual step that isn’t strictly needed and can lead to operational mistakes on our end. So we want to set things up so that the administrators of the system can set more than 100 classes in a day without needing to resort to this.

The only way I could think of to come around this was to have a few administrator accounts (administrator+1, administrator+2, administrator+3, etc.) and then use these accounts round robin, but that feels very hacky.

(Of course, the easiest solution would be to just increase our API limit to a few hundred for the administrator account that we’re using, but I’m not sure if this is possible or not. I already tried contacting our sales representative, he directed us to here.)

Is there a recommended way to do what we want?

I might have found a really simple solution to my own problem. I decided to post in in case it helps someone else later.

Before, I using this URL format:

url = “https://api.zoom.us/v2/users/adminaccount@example.com/meetings

I changed it to this:

url = “https://api.zoom.us/v2/users/coachaccount@example.com/meetings

I didn’t realize that my JWT token would be useable on the coach API URLs too.

OK, that didn’t work as expected unfortunately. When I first create the meeting things work as expected. But if I later try to change the schedule_for setting on the meeting, it seems that I can’t do it and I get a 3000 “You cannot schedule a meeting for example@example.com” error.

I tried a different approach, which also failed, but for the life of me I can’t understand why it would fail.

  1. I create a meeting using the URL above:

url = “https://api.zoom.us/v2/users/user1@example.com/meetings”

This works as expected.

  1. I set the meeting’s host to instead be the admin account. My idea was, if I can’t set it from user1@example.com to user2@example.com directly, I could instead set it from user1@example.com to admin@example.com first, and then set it to user2@example.com, assuming that I set all of the necessary assistant permissions.

The first part of this worked:


However, now I can’t do this:


It is very odd though, the host for the meeting now shows as admin@example.com, and admin@example.com is listed as an assistant for user2@example.com. But when I try setting the host on the meeting again, I get this dreaded response:

{‘message’: ‘You cannot schedule a meeting for user2@example.com.’, ‘code’: 3000}

I have no idea why this would happen though. I tried setting admin@example.com as an assistant for user2@example.com and even tried the other way (setting user2@example.com as an assistant for admin@example.com) and neither worked. My guess is that, because the meeting was created under user1@example.com, the meeting is stuck to his account “somehow” despite me changing the host to admin@example.com

Someone, please help!!! :frowning:

One more thing to note. If I login as admin@example.com, I can change the above meeting to user2@example.com without a problem… so it seems to be some limitation of the API that the admin interface doesn’t have.

We face similar levels of scale limitations to conserve the number of licensed users; what we do is maintain our own schedule of when each logical host user (from our perspective) is scheduled for a meeting and spoon feed Zoom only the next meeting information for each physical host user (from Zoom’s perspective). Once the previous meeting finishes, we edit that meeting to match the scheduling for the next logical host. If we reach an API rate limit, then we need to switch to another physical host that hasn’t reached a rate limit yet. Keeping the intended schedule on our side means that schedule changes don’t count against rate limits unless it was the next meeting.

For starting the meeting, we direct users to our own web site which figures out which physical host is being used and instructs the logical host which physical user to log in as (using an OAuth application to query Zoom to see which physical account they are currently signed in as in their web browser and instruct them to switch users if needed, or redirect them to the meeting if they’re already in the correct account).

You might be able to get additional ideas by searching for ways that people share Zoom licenses. I heard one technique involves disclosing the host key for the physical host and having the logical host use that to claim the host role when the meeting begins,

Hi @peter.kaufman ,

Can you please share patch request code you sent for assigning the assistant?

Try referencing these post for possible programmatic solutions:

Thank you,