Description
We are encountering errors indicating that the Next Page Token is invalid or expired, despite using the token value returned in the previous API response. The API call is passing the exact Next Page Token provided by the API into the subsequent pagination request, but the API continues to reject the token as invalid or expired.
How To Reproduce Steps to reproduce the behavior: 1. Call the Archive Files API & have enough meeting/webinar data so that it returns a next page token. **There needs to be a minimum of two next page tokens in order to reproduce the behavior. One next page token will not reproduce the issue. 2. Make the same Archive Files API call, but this time passing in the Next Page Token value. For us, this first pagination is successful. 3. Make the same Archive Files API call, while passing in the Next Page Token value provided by the previous API response. This is when the error starts happening. Processing fails at this point.
Here is the header information:
x-zm-trackingid: v=2.0;clid=aw1;rid=WEB_3e52a78c681ee34c265b8a81771ba31a
Let me know if there is something else that is needed.
As a heads up, we are a compliance archiving Zoom partner and we are having clients experience this same issue in their environments as well.
Hi @emason1 , thanks for your patience, I’ve marked this a priority and will share as soon as it’s become available. I’ve marked this a high priority (ZSEE-217554).
Thank you! We have a client that is coming up on day 40 of their maximum 60 day retention on this API before they start losing data so I will also share their tracking number once I have it.
On a side note, has Zoom discussed increasing the maximum 60 day archive retention?
As an update, the issue seems to have resolved itself… I’m not sure if there was a change on the Zoom side as we have not changed anything on our end, but it seems to be working today & yesterday. We are seeing positive results from our clients environment as well so we are catching them up now.
That error usually means the token was used after it expired or a query parameter changed between pages, so keeping the from, to, page size and query date type exactly the same and using the token right away is worth checking if it comes back. When we hit the same problem on a client archive sync, the team at Zabeel Marketing Dubai found that re-running the first page for a fresh token cleared it when an older token had already timed out.
@emason1@Johan2 , This appears to be by design and expected, the end user needs to adjust the “to” value to match what was returned in the last payload, otherwise it will return an error. See documentation here: Meetings API - Meetings - Zoom Developer Docs
"Note: if you use next_page_token as a parameter, your other request parameters should be changeless to make sure that the large result set is what you want. For example, if your to parameter is for a future time, Zoom resets this value to the current time and returns this value in the response body, along with the next_page_token value. Use these same to and next_page_token values in requests for the remaining results set; otherwise you will get an invalid token error.”
I missed it given I had reviewed the “query_parameters” and “error code” sections and not seen that info there.
Erica, since you said it resolved itself with no change on your end, there seems to be an output inconsistency with this endpoint so I’ve flagged that with the team.
Were the engineers investigating this issue able to provide any feedback regarding the root cause?
I can confirm that the request parameters remain consistent across all three API calls. As shown in my initial post, each call uses the same date range, query_data_type=archive_complete_time, and page size. The only difference is that the first API call does not include a next_page_token, as expected for the initial request.
To address @Johan2’s comment regarding token expiration, we explicitly refresh the access token before initiating any data collection to ensure it is valid. Additionally, we confirmed that other API calls, such as the /users endpoint, were completing successfully using the same access token prior to the Archive Files API calls.
Based on this behavior, we do not believe token expiration was the cause of the issue, particularly since the failure occurred during consecutive Archive Files API calls using the same token and consistent request parameters.
We would appreciate any additional insight from the engineering team regarding what caused this behavior.
