Questions about Zoom API (and Zoom account features, and how they interact)

This is more of a preface to any sort of technical questions.

I’m in the concept phases of a service that integrates with the Zoom API to automate meeting generation and possibly even account creation pursuant to service delivery.

I notice that I can indeed create users through the User Create Endpoint but I’m not clear on how limited such users would be (can I create users that can schedule, or have meetings scheduled on, their behalf? If so, do I have to alter my API access credentials after creating them, to match the new user’s credentials, in order to set up meetings for them?) and what would happen if I attempted to create users on an account that was already at its user limit.

I notice that the rate limit for the Meeting Creation Endpoint is restricted to 100 requests per day. Is it possible, with certain tiers of service or direct communication with Zoom’s staff, to relax this rate limit in the event that usage results in the creation (or attempted creation) of over 100 meetings per 24 hour period? Or is this immutable?

Any clarification/advice on the above would be greatly appreciated, and thanks for your time!

Hey @kevin.barsotti,

You can use your accounts JWT Token to Create users, and schedule meetings for those users.

What is your use case for needing to schedule more then 100 meetings per day per user?

Thanks,
Tommy

1 Like

Hey, @tommy - thanks for the reply. Just to be sure, these users are in no way different in terms of privileges/access as one added manually/personally?

Regarding the rate limit, the use case that concerns me is a lot of front-loaded scheduling of events out through a three or four month window. It’s a distance learning/education type deal where any individual presenter/instructor might well publish a curriculum that amounts to triggering the scheduling of five or ten meetings per week for an eight to twelve week quarter or semester.

That being said, I had thought the limit was per implementation general implementation, not per user. Between that and solutions like queueing and forcing submission of curricula a respectable timeframe before the first meeting needs to be scheduled, I’m sure that any number of user-friendly workarounds/concessions are possible.

And I’m running into a terminology issue, I think - looking at the service tiers of Zoom, is there a practical difference between a user and a “host” when it comes to plan limits/costs? Like, will users added through API calls increase billing on the attached plan immediately (but also be able to act as hosts of meetings)?

Or am I misunderstanding what constitutes a user versus a service subscriber or host?

Hey @kevin.barsotti,

Correct.

You can specify what plan the users you create via API are on. If they are free users you won’t be charged extra.

A free user can be a host, but a free host can only host meetings up to 40 minutes.

Thanks,
Tommy

1 Like

I’m curious, is there documentation out there explaining the distinction between Basic (I’m assuming this is the same as free?), Licensed, and On-prem users?

What attributes govern whether or not a user can schedule their own meetings or who has control over these users/meetings?

It seems like creating new users and in turn under said users creating meetings is the practical/intended way to “automatically generate Zoom meetings” for a multi-user service.

While we do want/need the software-generated users to be hosts of meetings, we’re probably going to want to restrict software-generated users’ such that they (as well as their software-generated meetings) are as tightly controlled by actual staff users as possible. Not scheduling their own meetings manually or manually altering software-scheduled meeting information after-creation.

Likewise, recording is an important feature - we’d need to make sure that recordings are automatically set up to run, and end up under the access/control of the staff and not the software-generated user once the meeting is over.

Are the above scenarios things we can control during user/meeting creation or update?

In terms of e-mail addresses to set users up under, I see that it’s possible to get a bounce if their e-mail is already registered with a Zoom account. Does Zoom support username+parameter@domain.tld format e-mail addresses for user creation such that we can create Zoom users intended for use with our meetings even if their original address (username@domain.tld) address is already registered with Zoom in some capacity?

Hey @kevin.barsotti,

Yes, checkout the account types here:

Can you clarify your use case surrounding this question?

Yep, the other flow is to use OAuth, which allows existing Zoom users to connect their accounts to your app so you can make API requests for them.

Yes, you can adjust the recording settings respectively for each user.

Yes, that should work. Also if the email already has an account, you can request to merge that account into your account:

Thanks,
Tommy

That account type article is super helpful, thanks!

What attributes govern whether or not a user can schedule their own meetings or who has control over these users/meetings?

Can you clarify your use case surrounding this question?

Essentially, we want to set up vendor type users as hosts of meetings that they will be delivering (distance educational sessions) - but they remain at the core of the service a type of user, so the concern is that they not have too much ability to access and mess with their zoom settings beyond hosting the meetings to which they are automatically assigned. Those settings would ideally be something staff could manage, but not users.

This ties into another question:

Yes, you can adjust the recording settings respectively for each user.

Is it possible to adjust recording settings in such a way as to record multiple users’ meetings under a single (staff) user’s account? Like, regardless of which of the hypothetical vendor types delivers a distance learning session, the staff’s account receives/has access to the recording (rather than the vendors themselves).

Effectively we want to make the Zoom aspect of the service delivery as automatic/hands-off as possible for both the primary hosts (I am assuming the staff would need to be secondary hosts at least, but if all the staff are primary hosts we run into issues with limited numbers of concurrent per-staff-member meetings faring poorly against a potentially unlimited number of scheduled distance-learning sessions).

Given that we want this to be fairly unobtrusive (like we don’t want to take over the Zoom accounts of vendors who may well have/use those accounts for other entirely distinct purposes, only create accounts with us for our service) adding existing users seems like it won’t really be necessary.

Hey @kevin.barsotti,

You can manage the user permissions here:

At a base level, the users can only control their own settings and meetings.

Account owners and admins can see the recordings of their members. You can also use our recording APIs and Webhooks.

Thanks,
Tommy