Suddenly getting 401s after s2s oauth worked for a week

Affected endpoints

  • POST /v2/users/:userId/meetings
  • DELETE /v2/meetings/:meetingId

App type

server-to-sever oauth


We have a Zoom server-to-server oauth app. Our service code uses this Zoom oauth app to create and delete Zoom meetings. Here’s a typical flow:

  1. create_zoom_meeting()
  2. Check whether a non-expired Zoom access token exists in our data store.
  3. If so, use it for making the request to Zoom to create the meeting.
  4. Otherwise, obtain a new access token from Zoom and save it to the data store.

This integration worked great for about a week. Then, we suddenly started getting 401 responses from Zoom on every request to every Zoom API endpoint.

What we tried:

  • The access token was not expired.
  • Even if we ignored the cached access token and just requested a new token from Zoom immediately before making the request to create/delete a meeting, we still got a 401.

We were able to reliably reproduce the 401 response.

…but it started working again

Without any code changes, we started getting successful responses to these requests after making these two non-code changes:

  1. We transferred ownership of the Zoom oauth app to another Zoom account.
  2. We rotated the client secret.

Immediately after making those 2 changes, we started getting successful responses from Zoom’s APIs.


401 response


After reading other forum posts, we realized that there’s a max number of access tokens that Zoom issues before invalidating the previously issued ones that are not yet expired.

We added a fix to a race condition that could cause concurrent processes to all call Zoom to fetch a new access token, potentially exceeding that max number.

The questions

  1. Why would transferring ownership of the Zoom oauth app and/or rotating the client secret cause us to start getting successful responses?
  2. Before fixing the race condition, we might have called Zoom to fetch new access tokens too many times in a short period. Is it possible that Zoom blocked our oauth Zoom app because of this, such that we would always receive 401 responses? Note that we also tested fetching a new access token with a single process immediately before sending the API request to Zoom and still got 401, so we know that the fetched access token was valid during those tests despite getting a 401 response.
  3. Is there any action we might have taken with our API access that would have caused Zoom to block our oauth Zoom app and get 401 responses until we rotated the client secret? I don’t know if the app was blocked or not, but the 401 responses are suspicious.
1 Like

Hi @JamieH

The s2s OAuth apps scopes and tokens are tied to the developer role permissions . If the developer is not longer the part of the account or their role permissions change, the app may not function properly.