Restrictions by ZoomAPI Specification

[suzunosuke.miyahara (宮原)]

What are the limitations due to the ZoomAPI specification?
We are currently aware of the following two.
We would appreciate it if you could tell us as much as possible.

(1) The maximum number of API connections per user is 100 per day. If the upper limit is exceeded, API linking cannot be implemented until it is reset at 9:00.
(2) The refresh token is valid for 90 days, after which API integration cannot be performed.

Is there anything else?

We would like to know in advance if there are any restrictions to ensure the safe operation of the system we are building.

I would appreciate it if you could address this issue.

[MultiplayerSession (Christopher Lee [MVP])]

The API Reference Introduction has a section on authentication (but you should consult the documentation for your specific application type for more specific token expectations), and there is a dedicated article for rate limits. What are you hoping to build?

[suzunosuke.miyahara (宮原)]

Thank you for your response.
I also apologize for the delay in replying.

We are building a conference reservation system using ZoomAPI.
There are 8 types of ZoomAPI that we plan to use.

1．Get a meeting (Light)

2．Create a meeting (Medium)

3．Update a meeting (Light)

4．Delete a meeting (Light)

5．Get a user (Light)

6．List user assistants (Medium)

7．Add assistants (Medium)

8．Delete user assistants (Light)

Example of use)
・When the reservation button is clicked from our system, ZoomAPI (Create a meeting) is called and a Zoom meeting is created.

・When the “Open” button is clicked from our system, ZoomAPI (Get a meeting) is called and the Zoom meeting is started.

However, due to limitations of ZoomAPI, an error code may be returned when calling ZoomAPI.
The two we are aware of are as follows.

(1) The maximum number of API connections per user is 100 connections per day.
If the limit is exceeded, API calls cannot be performed until the call count is reset at 9:00.
（ Rate limits）

(2) The refresh token is valid for 90 days, and when it expires, ZoomAPI will not be available unless the application authentication is performed again.
（ ユーザー承認済みアプリの OAuth）

Are there any other restrictions other than the above that prevent the use of ZoomAPI due to ZoomAPI restrictions?
If there are other restrictions, we need to design our operations to accommodate them.

[MultiplayerSession (Christopher Lee [MVP])]

Our Server-to-Server OAuth application uses APIs that are similar to the ones you use, and we only handle rate limiting and the refresh token.

For rate limiting, we aren’t sensitive to errors because we store in our system what the desired configuration should be, then an on-demand or periodic process will compare that to what Zoom has and make changes to bring Zoom into alignment with what we want it to be. Even if there’s an error, we’ll retry later on and compare again. So we don’t specifically handle this error.

For the refresh token, the behavior we have for our Server-to-Server OAuth application might be different from the kind of application you’re building. For high availability, we had to implement our own key rotation strategy. I’ve outlined a proposed two-key rotation strategy if you have a shared database that relies on exactly one process succeeding on an UPDATE / WHERE statement matching the original renewal time. This was implemented at a time when Zoom only supported one valid access token at a time per application; that access token limitation is relaxed now but I don’t have experience with the new behavior, as we haven’t updated to account for that. If you’re building a different kind of OAuth application, this might not apply to you.