Rate limits

Rate limits define the maximum number of requests a single account can make within a given period of time. When you exceed a rate limit, the API request will fail and return a HTTP 429 status code.

Rate limits are applied at the account level. These rate limits are shared by users for all apps installed on the account.
Rate limits are applied based on your account plan. Increased rate limits are 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 in the documentation for each API.
Some APIs have special rate limits at a the user-level.
Some APIs have limits on concurrent operations performed on a single resource.

Important

The Zoom API uses rate limits to ensure that API request traffic is efficiently handled. We may alter these limits as needed. To stay up to date on any rate limit changes, read our changelog.

Rate limits by account type

Rate limits are applied based on the account plan: Pro, and Business+ (Business, Education, Enterprise & Partners). The following outlines the rate limits applied to APIs by rate limit type for each account plan:

	Pro Accounts	Business+
Light APIs Light rate limits apply to creating, reading, updating, and deleting a single resource. For example, the Get a user API.	30 requests per second.	80 requests per second.
Medium APIs Medium rate limits apply to creating, reading, and updating multiple resources at once. This rate limit also applies to Chat-related APIs, such as the List group members and Send a chat message APIs.	30 requests per second.	80 requests per second.
Heavy APIs Heavy rate limits apply to Report APIs and most Dashboard APIs. For example, the Get meeting details API.	10 requests per second. Daily limit of 30,000 requests per day, shared by heavy and resource-intensive APIs.	40 requests per second Daily limit of 60,000 requests per day, shared by heavy and resource-intensive APIs.
Resource-intensive APIs The following APIs are categorized as resource-intensive: List meetings List webinars List Zoom Rooms (DEPRECATED) Get IM metrics	10 requests per minute. Daily limit of 30,000 requests per day, shared by heavy and resource-intensive APIs.	20 requests per minute. Daily limit of 60,000 requests per day, shared by heavy and resource-intensive APIs.

User-level rate limits

The following are special user-level rate limits:

Daily meeting create and update requests

A single user can only make 100 create, update, or delete meeting requests per day (UTC). This 24-hour period resets at 00:00 UTC, not the user or account’s local timezone. This rate limit is tracked by the user’s ID and applies to all Meeting IDs they host. However, this rate limit is not shared across an account. For example:

A user sends 100 requests to create a meeting. On the 101st request to create, update, or delete a meeting within a 24 hour period, the attempt fails and the API returns a 429 rate limit error. At 00:00 UTC the user can resume creating and/or updating meetings.
A user sends 50 POST requests to create meetings. The user then sends PATCH requests to update all 50 meetings. When the user attempts to delete all 50 meetings, the request fails. Any request after the first 100 requests returns a 429 rate limit error. However, at 00:00 UTC, the user can resume creating and/or updating meetings.

Daily webinar create and delete requests

We are introducing new rate limits to Create a webinar and Update a webinar APIs. Starting October 23, 2021, these endpoints will have a rate limit of 100 requests/day per user.

A single user can only make 100 create and update webinar requests per day (UTC). This 24-hour period resets at 00:00 UTC, not the user or account’s local timezone. This rate limit is tracked by the user’s ID and applies to all webinar IDs they host. However, this rate limit is not shared across an account. For example:

A user sends 100 requests to create a webinar. On the 101st request to create or update a webinar within a 24 hour period, the attempt fails and the API returns a 429 rate limit error. At 00:00 UTC the user can resume creating and/or updating webinars.
A user sends 50 POST requests to create webinars. The user then sends PATCH requests to update all 50 webinars. If the user attempts to make any additional create or update webinar requests, the API returns a 429 rate limit error. However, at 00:00 UTC, the user can resume creating and/or updating meetings.

Daily registration requests

A single user can only make a maximum of 3 requests per day (UTC) for the same registrant in the same meeting or webinar for the following APIs:

Daily registrant status requests

A single user can only make a maximum of 10 requests per day (UTC) for the same registrant in the same meeting or webinar for the following APIs:

Zoom Phone APIs

Zoom Phone APIs are rate limited by request type and applied based on the account plan:

	Pro Accounts	Business+
Light APIs Light rate limits apply to creating, reading, updating, and deleting a single Zoom Phone resource. For example, the Create a call queue API.	20 requests per second.	40 requests per second.
Medium APIs Medium rate limits apply to creating, reading, and updating multiple resources at once. For example, the List phone numbers API.	10 requests per second.	20 requests per second.
Heavy APIs Heavy rate limits apply to the Zoom Phone Get user’s call logs and Get account’s call logs APIs.	5 requests per second. Daily limit of 30,000 requests per day, shared by heavy and resource-intensive APIs.	10 requests per second. Daily limit of 30,000 requests per day, shared by heavy and resource-intensive APIs.

Limits to concurrent requests

If concurrent requests are made to a single resource (for example, concurrent GET/POST/PATCH/PUT/DELETE requests to a single user ID), then the request will fail with a 429 HTTP status code and error message.

Concurrent rate limit errors 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 similar to the following:

Too many concurrent requests. A request to disassociate this user has already been made.

Error handling best practices

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. APIs with daily rate limits will send a Retry-After header with the response that indicates when you can make the next request.

The following table 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 that you use webhooks to subscribe to data change events instead of polling for changes. For example, instead of polling for a user’s meetings, use webhooks to subscribe to events for new, updated, and deleted meetings.