S2S OAuth Token invalid before 3600 seconds are over


from time to time it happens that a created S2S OAuth token becomes invalid and cannot be used anymore for API consumption before the 3600 seconds of validity are over.

Unfortunately I could not reproduce the problem yet when I was trying to in order to restrict it to a certain behavior of our API clients . But from a gut feeling it happens after this token has been used for creating/deleting users and/or creating/deleting meetings.

Does anyone have an idea what could be the problem, or even similar experiences?


Do you have multiple instances of your application running at the same time (e.g. in a clustered environment)? You might be running into the undocumented “feature” where the previous OAuth token is invalidated when you request a new one.

Indeed, that’s the reason. I can now reproduce this behavior reliably.

However, I don’t get your linked solution to work. When I try to create a token and pass a token index like this:

I get the error message 400: Invalid request : Maximum group number limit exceeded

Do you know how to get that solved?

Ok, now it’s clear: Server-to-Server OAuth: annoying token-invalidation

ZOOM needs to increase the available number of token indexes manually in their backend, and it can be set to 3 max.

Yeah…it’s a pain. You have to pester Zoom to get the index limit increased. Sorry that wasn’t clear in my original post.

At the moment kind of, yes. But the problem in fact is, that it is apparently not documented anywhere. When it is documented, you can take it into consideration.

Then I see two options:

  1. You create a new token every time you want to call any API. This is surely not how it should be done because the token is valid for one hour, and it would decrease performance of your app.

  2. You save the token somewhere in your DB together with a valid-to timestamp. Then you can reuse it every time you need it, and create a new one when the valid-to moment has been reached.

I think I will go for the second option.

FWIW, we did option #2 as well, only we didn’t store it in the DB, we used AWS Secrets Manager. We also wrote a scheduled Lambda that would rotate the token every 50 minutes