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.)
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 email@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.
One more thing to note. If I login as firstname.lastname@example.org, I can change the above meeting to email@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,