New Zoom V2 REST API Rate Limiter coming in March 2020
By: Benjamin Dean
Tags: Developer, Rate Limiting, Zoom, Apps, API

To ensure Zoom’s V2 REST API continues powering your business automations and Marketplace apps at scale, we will be releasing new V2 REST API Rate Limits in March 2020!

What‘s wrong with current V2 API Rate Limits?

Zoom’s Platform Engineering Team continually monitors activity and usage of our APIs for all our customers. Last year, we identified the need to improve the current “one-size-fits-all” V2 API Rate Limits to continue satisfying customer demand of our V2 API.

Screenshot of current global Rate Limits as published on Zoom Developer Docs in Feb 2020

Current V2 API Rate Limits are the same for all Zoom Plans with access to the API: Pro, Business, Enterprise, and so on as published in the Zoom Developer Docs. The current API Rate Limits will not scale with customer’s organization growth AND their increased usage of the V2 API.

In March, we’ll release the new API Rate Limits, and this can impact your apps and code, so I wanted to share these changes…

What is Changing?

The new V2 API Rate Limiter being released in March 2020 has been a huge improvement and will ensure Zoom scales to satisfy both your organization size and usage volume.

The new API Rate Limits are based on the Customer’s Account Type + API Request Group.

How are Zoom Customer’s Account Types Defined?

For this first iteration, we’ve defined Account Types by making two logical groups of Zoom Plans…

Table showing the logical grouping of Zoom Plans to create “Account Types” for new API Rate Limits

What is an API Request Group?

API Request Groups, also called Request Types, are another logical grouping we’ve created grouping APIs with respect to infrastructure importance and load-intensity we need available to power the respective APIs for all our customers.

New V2 API Rate Limits

We combine the Account Types and cross-reference them with the Request Types, and that is the new V2 API Rate Limits that will be coming in March 2020! In most use cases, your V2 API Rate Limits are going to increase!!! The one exception is the Resource-Intensive Dashboard API Request Group going from 1 req/sec ==> 6 req/min for Pro account types, and 12 req/min for Business+ account types.

Screenshot from docs, as of March 12, 2020, showing the new V2 API Rate Limits

New Rate Limit Response Headers

Rate-limited requests will receive an HTTP Response with the following additional headers. Since we have different rate limits for day and minute , we only include X-RateLimit-Reset (number of seconds since Unix epoch) header on per-minute 429 responses, and we only include Retry-After (ISO8601 datetime). If the X-RateLimit-Remaining === 0, you must wait until the X-RateLimit-Reset or Retry-After values to re-execute the throttled request.

PER-MINUTE RATE LIMIT RESPONSE HEADERS

* X-RateLimit-Limit: 5000

* X-RateLimit-Remaining: 4999

* X-RateLimit-Reset: 1372700873 PER-DAY RATE LIMIT RESPONSE HEADERS

* X-RateLimit-Limit: 1

* X-RateLimit-Remaining: 0

* Retry-After: 2019–10–31T00:00:00Z

Lock-Key RateLimits

We have a handful of identifiers, we call “lock-key”, that are commonly used as part of Path Variables in V2 REST API requests, which will have some special limitations of importance to developers.

A screenshot of the Lock-Key RateLimit Restrictions (described below in the bulleted list)

The userId , userEmail on the following routes can restrict ability to perform specific operations, you will receive an HTTP 429 response for these cases as well:

Cannot create/update more than 100 meetings for a single user in a single day.

While executing a POST request to any API with prefix /v2/users you will be UNABLE to: [GET, PATCH, PUT, DELETE] until the POST operation has completed successfully.

you will be UNABLE to: [GET, PATCH, PUT, DELETE] until the POST operation has completed successfully. Only one (1) DELETE for a specific userId will be accepted, to prevent attempts at concurrently deleting a specific user.

will be accepted, to prevent attempts at concurrently deleting a specific user. Only one (1) POST to /v2/users/{userId}/tsp can be performed at a time, any additional requests will be rate limited until the initial POST request is complete.

can be performed at a time, any additional requests will be rate limited until the initial POST request is complete. Only one (1) PUT to /v2/accounts/{accountId}/users/{userId}/account can be performed at a time, any additional concurrent requests will be rate limited until the initial PUT request is complete

How You Can Prepare for the V2 API Rate Limit Changes

Handle HTTP 429 responses properly — When your app receives an HTTP 429 status code response, identify the customer from the correlating Request’s access_token and evaluate the response headers which provide retry logic data to re-attempt rate limited requests. Don’t long-poll the Zoom API. Update your app to include event subscription(s), filter incoming events to free up API requests whenever possible.

You can read the full Upcoming Rate Limit Changes announcement documentation to obtain greater detail and more information about specifics. If you have any questions, please ask them on the Zoom Developer Forum.