429 Pagination cursor expiration, retry-After header param missing

API and Webhooks
1

API Endpoint(s) and/or Zoom API Event(s)

Description

Many of the zoom customers facing issues with 429 rate limit, particularly for the heavy endpoint like get meetings endpoint. For business + users we can call only 60000 api calls per day as per docs, and we have connected with zoom team regarding these api limits if they can increase or not.

Other two issues are interlinked with this 429 issue those are

  1. Pagination cursor expiration
  2. Retry-After header param missing from header response.

So here Pagination cursor expiring in 15 min for users endpoint and we have to pass user id’s in list meetings endpoint and then we have to pass meeting id’s in get meetings endpoint and also in between we other dependancy endpoints to call, by the time to call all of these our pagination cursor is expiring here.

So if we limit api calls from our end lets say 60000 to 57000 then there are very high chances to cross the 15 min expiration time.

Another issue is we are not getting retry-after header param in response header, but docs saying we will get retry-after param if we get any rate limit issue.

2

Hi,

Can you add some examples? please remove any user PII info.

3

Hi,

  1. Pagination cursor expiration:

While executing the USERS endpoint in Postman, we set the page size to 100, and there were a total of 138 records. When testing the WEBINAR_REGISTRANT endpoint with the 18th user ID, the cursor expired after 15 minutes, resulting in a 400 response. Consequently, we missed the records that we would have obtained by passing the next 82 user IDs.

  1. Retry-After parameter missing in header section:

We are not getting Retry-After parameter in headers.

  1. Incremental sync:

Despite the presence of incremental sync functionality in the MEETING endpoint, it isn’t functioning as anticipated. We’ve verified data availability for a specific date for a given user ID.
But while keeping from and to parameter, we are getting empty response.
Upon inspection of another user ID, the incremental parameter is functioning properly.
This inconsistency is unexpected, as the incremental parameters should ideally operate consistently across all user IDs.

Please refer the attached images.

5

Screenshot:
https://docs.google.com/document/d/1EqG7qp6ZFZSYtr2KLVO763fC3eVvvg0Xo9wj2HrpyeQ

6

Hi @fivetrandevs ,

Thanks for clarifying.

  1. Pagination Token:
    The pagination token by design will expire within 15 minutes. Once you have a pagination token, please make sure to use it promptly or use a new pagination token.

  2. Retry after: retry after is typically for rate limit errors (although I am not sure if we implement that in zoom). Since your case is not a rate limit related error, I dont think you will see the retry parameter.

  3. Can you provide examples for the 3rd one?

7

Hi Zoom developer’s team,

Thank you for clarifying about the pagination token.

However, we’ve encountered instances where this parameter isn’t present for certain customers. Additionally, in the documentation, it’s specified as “Retry-After,” but for some customers, it appears as “retry-after” instead. Moreover, while some customers receive “Retry-After” in the header response for rate limits, others receive no header response at all.

Does the availability of the rate limit parameter depend on the type of customer account?

We’ve also conducted tests on incremental parameters across different customer accounts. In one customer account, even though there was a record for 2024-04-03, when filtering records from 2024-04-02 to 2024-04-05, we received an empty response as shown in the screenshot.

Conversely, incremental parameters work for another customer. Is this discrepancy related to the type of Zoom plan the customer has?

Please refer the document link above message for detailed explanations and screenshots. We can also go on a call for a more thorough discussion of the issues here.