Announcements

Below are upcoming changes to the Zoom Developer Platform.For recent changes to the Zoom API, Marketplace and SDKs, refer to our Changelog.

Last updated January 8, 2020.

Upcoming V1 APIs End of Life

On April 26, 2020, the Zoom V1 APIs will be permanently shut down/terminated and will no longer be in operation.

To prevent service interruptions, you must migrate to the Zoom v2 APIs.

Migrate your business automations onto our more advanced/secure v2 APIs, and ensure your Zoom integrations continue operating normally. As an added benefit, once you migrate, you’ll have access to developer support, a much broader library of APIs, webhooks, and more!

No exceptions will be made and Zoom Customer Support will be unable to assist you if you do not migrate before the deadline.

Read our blog Your Guide to Migrating From v1 to v2 APIs and to review our new API documentation to learn the differences between the v1 and v2 APIs, and for instructions how your developer can successfully migrate your integrations to our new v2 APIs.

If you have any questions about these changes, or if your developers need technical support using the new V2 APIs, please visit our Zoom Developer Forum.

Rate Limit Changes

This announcement defines new rate limits to go in effect March, 2020.

To ensure long-term scalability and growth of our developer’s ever-increasing usage of the REST API and Marketplace apps, the Zoom API will implement new rate limit strategies, effective March 2020.

For most endpoints, rate limits will be doubled for all Pro accounts and quadrupled for all Business, Enterprise, Education and Partner accounts.

What’s changing?

Rate limits will be defined by account plan, with higher limits available for all Business, Enterprise and Education accounts. As with the previous rate limit strategy, rate limits are applied at the account level. Rate limits will be shared by all apps created and installed on an account.

APIs will now be grouped by Request Type, with unique rate limits for each. A “Rate Limit Label” will be added on each section in our API Reference documentation for each endpoint.

Some APIs will have restrictions on concurrent operations performed at the resource level (for example: simultaneous updates to a single userID).

With these changes, rate limits will now vary depending on the account plan and the type of request that is being made. Use the table below to understand how rate limits will be applied:

Account Types

Type Description
Pro Accounts that have purchased the Pro plan.

Business and higher

Accounts that are on Business Plan, Education Plan, VIP Plan, API Partner Plan and Enterprise Plan.

Request Types

Type (Label) Description
General Create, Retrieve, Update, Delete a single resource. Example: Get Details about a Specific User, Update User Status etc.
Batch Create, Retrieve and Update multiple resources at once. Examples: List Group Members, Add Members to a Group etc.
In addition to this, Chat API requests (Chat Contacts, Chat Messages, Chat Channels) will also be rate limited in the same manner as the Batch Requests.
Resource-intensive All Reports APIs and most Dashboard APIs. Some Dashboard APIs have stricter rate limits than the Resource-intensive APIs and these APIs can be identified by the Resource-intensive(Dashboard)* label.

Resource-intensive(Dashboard*)

Dashboard APIs with following endpoints:
GET /v2/metrics/meetings
GET /v2/metrics/webinars
GET/v2/metrics/zoomrooms
GET /v2/metrics/im

To ensure that you are incorporating the correct rate limits in your code, a “Rate Limit Label” section in the API reference document will be added for each endpoint you will be using. Use the table below to understand the upcoming rate limits by type.

Rate Limits

API Request Groups (Labels) Account Types and Corresponding Rate Limits

Pro Accounts

Business, Education, Enterprise & Partner Accounts

General
Create, Retrieve, Update, Delete a single resource. Example: Get Details about a Specific User, Update User Status etc.
20 requests/second 
 
40 requests/second 
Batch 10 requests/second  20 requests/second 
Resource-intensive  5 requests/second 
30,000 requests/day
10 requests/second 
60,000 requests/day

Resource-intensive(Dashboard*) 

6 requests/minute  12 requests/minute 

Additional Rate Limits for Concurrent Requests

If concurrent requests (GET/DELETE/PATCH/POST/PUT) are being made on a single resource, the request will fail and you will recieve an error message along with a 429 HTTP status code.

Concurrent rate limits error will occur in rare cases such as when your app makes multiple requests in a short period of interval to . In this scenario, you will receive the following error message:
Too many concurrent requests. A request to disassociate this user has already been made.

Similarly, you can not create/update more than 100 meetings for a user in a single day.

Limits to Concurrent Requests & Single Resources

Under new rate limits, requests performing update operations on a single resource (userID, meetingID, werbinarID, accountID) may not be made concurrently (simultaneously). Any requests making concurrent operations will fail with a 429 error code.

Concurrent GET requests may still be made on a single resource. When a request to update the resource is made (POST/PUT/PATCH/DELETE); however, any concurrent request will fail (including a concurrent GET request).

These types of concurrent request errors will only occur in rare cases, for example, when two requests are made to disassociate a user from an account. In this scenario, a descriptive error message will be sent:

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

In addition, update requests on single meeting resources may have some limits. For example, one userID may only have 100 meetings created or updated in a single day.

Best Practices for Handling Errors

When you exceed the rate limits allowed for an API request, you will receive a “429 Too Many Requests” error. The best way to handle rate limits is to be on the lookout for 429 status codes and build in a retry mechanism that makes reduced number of requests to the server in a given timeframe.

For APIs that have daily rate limits, a Retry-After header will be included to the response indicating how long you must wait before making the next request. The table below lists the errors that you might encounter when you reach the rate limits.

Rate Limit Type HTTP Status Codes Error Messages

Regular Rate Limit

429

You have reached the maximum per-second rate limit for this API. Try again later.

Daily Rate 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-Limit: 30000
X-RateLimit-Remaining: 10000
Retry-After: 2019-10-31T00:00:00Z

Cache responses whenever possible instead of frequently making the same request. We also highly recommend that you use Webhooks instead of polling for changes whenever applicable. Instead of making repeated calls to pull data frequently from the Zoom API, you can use Webhooks to get information on events that happen in a Zoom account. Learn more from the Webhook Reference guide.

To prevent abuse and handle API request traffic efficiently, we may alter these limits if required.

Early Notice: Changes coming to Batch List APIs

To provide for greater scalability of our Batch List APIs and provide for more consistent pagination methods, the pagination keys used for Batch List APIs will be changed from a page_number key to next_page_token.

Starting in March 2020, and over the subsequent three months, a new pagination page field (next_page_token) will be added to all REST API requests and responses under the following schedule:

March 2020:

Subsequent Releases Beginning May 2020:

Once all of the above APIs have support for next_page_token, you will have a six (6) month period to migrate from page_number to next_page_token. After the six month adoption window, the page_number field will no longer operate.

A notice will be sent once all Batch List APIs have been updated to support next_page_token, at which time the six month adoption window will begin.

Developer Readiness Guide:

Batch List API requests:

Currently, a page_number is used:

curl --location --request GET 'https://api.zoom.us/v2/groups/<GROUP_ID>/members?page_size=30&page_number=2'

During the adoption window, either a page_number or next_page_token can be used as a query param:

curl --location --request GET 'https://api.zoom.us/v2/groups/<GROUP_ID>/members?page_size=30&page_number=1'
curl --location --request GET 'https://api.zoom.us/v2/groups/<string>/members?page_size=30&next_page_token=lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3'

After the six (6) month adoption window, only a next_page_token can be used:

curl --location --request GET 'https://api.zoom.us/v2/groups/<string>/members?page_size=30&next_page_token=lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3'

Batch List API responses:

Currently, a page_number is sent in a Batch List response:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"page_number": 2,
		"page_size": 100,
		"total_records": 300
}

During the adoption window, both a page_number and next_page_token will be used:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"page_number": 2,
		"next_page_token": “lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3”,
		"page_size": 100,
		"total_records": 300
}

After the six (6) month adoption window, only a next_page_token will be sent:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"next_page_token": “lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3”,
		"page_size": 100,
		"total_records": 300
}

Need help?

The first place to look is on our Developer Forum. If you can't find the answer or your request includes sensitive information, contact Developer Support.