Rate limits
Rate limits define the maximum number of requests which can be made by a single account in a given period of time. When a limit is exceeded, an API request will fail with an HTTP 429 status code returned.
Rate limits are applied at the account level, and are shared by users for all apps installed on the account.
Rate limits are applied based on your account plan, with increased limits available for all Business, Enterprise, Education, and Partner accounts.
APIs are grouped by Request Type, with unique rate limits for each. A “Rate Limit Label” is available on the API Reference for each endpoint.
Some APIs may have special rate limits at a the user-level (but not many do). The main example of this is the Meetings API, outlined below.
Some APIs have limits on concurrent operations performed on a single resource, for example: simultaneous updates to a single user’s settings.
Note: Zoom Phone APIs have unique rate limits applied as outlined below.
Rate limits by account type
Rate limits are applied based on the account plan: Pro, and Business+ (Business, Education, Enterprise & Partners). The following table outlines limits applied to APIs by type for each account plan.
| Pro Accounts | Business+ | |
|---|---|---|
| Light APIs Create, read, update, and delete a single resource, e.g. Get A User. |
30 req. / second | 80 req. / second |
| Medium APIs Create, read, and update multiple resources at once, and Chat APIs, e.g. List Group Members, Send a Chat Message. |
20 req. / second | 60 req. / second |
| Heavy APIs Report APIs and most Dashboard APIs, e.g. Get Meeting Detail Report. |
10 req. / second Daily limit of 30,000 requests/day shared by heavy & resource-intensive APIs. |
40 req. / second Daily limit of 60,000 requests/day shared by heavy & resource-intensive APIs. |
| Resource-intensive APIs Dashboard APIs with the following endpoints: GET /v2/metrics/meetings GET /v2/metrics/webinars GET /v2/metrics/zoomrooms GET /v2/metrics/im |
10 req. / min. Daily limit of 30,000 requests/day shared by heavy & resource-intensive APIs. |
20 req. / min. Daily limit of 60,000 requests/day shared by heavy & resource-intensive APIs. |
Daily meeting create/update requests
A single user may only use up to 100 requests per day (UTC) to create, update, or delete meetings. This 24-hour period resets at 00:00 UTC, not the user or account’s local timezone.
This rate limit is tracked at the User ID and applies to all Meeting IDs they host; however, it is not shared across an account.
Example 1: User sends 100 requests to create a meeting. On the 101st request to create, update, or delete a meeting within 24 hours, a 429 rate limit error would be returned. At 00:00 UTC, the user may resume creating/updating meetings.
Example 2: User sends 50 POST requests to create meetings. The user then sends PATCH requests to update all 50 meetings. The user then attempts to delete all 50 meetings but may not. Any request after the first 100 will return a 429 rate limit error until 00:00 UTC.
Zoom Phone APIs
Zoom Phone APIs are also rate limited by request type and applied based on the account plan.
| Pro Accounts | Business+ * | |
|---|---|---|
| Light APIs Create, read, update, and delete a single Phone resource, e.g. Create a Call Queue. |
20 req. / second | 40 req. / second |
| Medium APIs Create, read, and update multiple resources at once, e.g. List Phone Numbers |
10 req. / second | 20 req. / second |
| Heavy APIs Get User's Call Logs and Get Account's Call Logs APIs. |
5 req. / second Daily limit of 30,000 requests/day shared by heavy & resource-intensive APIs. |
10 req. / second Daily limit of 30,000 requests/day shared by heavy & resource-intensive APIs. |
Limits to concurrent requests
If concurrent requests are being made on a single resource e.g. concurrent GET/POST/PATCH/PUT/DELETE requests to a single user ID, the request may fail with a 429 HTTP status code and error message.
These concurrent rate limit errors will occur in very rare cases, such as when your app makes multiple requests in a short period of time to disassociate a user from your account. In this scenario, you would receive an error message like:
Too many concurrent requests. A request to disassociate this user has already been made.
Best practices for handling errors
The best practice to handle rate limits is to handle “429 Too Many Requests” status codes and build in retry mechanisms for failed requests and to reduce the frequency of requests.
For APIs which have daily rate limits, a Retry-After header will be sent with the response indicating when you will be able to make the next request. The table below lists errors you may encounter:
| Limit Type | HTTP Status | Error Message |
|---|---|---|
| Per second limit | 429 | You have reached the maximum per-second rate limit for this API. Try again later. Example response header: X-RateLimit-Category: Light X-RateLimit-Type: QPS |
| Daily limit | 429 | You have reached the maximum daily rate limit for this API. Refer to the response header for details on when you can make another request. Example Response Header: X-RateLimit-Category: Heavy X-RateLimit-Type: Daily-limit X-RateLimit-Limit: 30000 X-RateLimit-Remaining: 0 Retry-After: 2020-05-31T00:00:00Z |
Cache responses wherever possible instead of frequently making the same request. We also highly recommend you use Webhooks to subscribe to data change events instead of polling for changes. For example, instead of polling for a user’s meetings, you could use webhooks to subscribe to events for new, updated, and deleted meetings. Learn more from the Webhook Reference.
The Zoom API uses rate limits to ensure API request traffic can be handled efficiently. We may alter these limits if required.