I’m getting random 401 errors using Server-To-Server OAuth when paging thru results from the report/meetings/meeting.uuid/participants endpoint.
I have a list of zoom meetings (size in the hundreds). For each meeting, I’m calling the /participants endpoint. With Server-to-Server OAuth, I get occasional 401 errors causing an incorrect list of participants. This seems to affect about half the meetings in my list, but it fluctuates with each try. Using JWT, I’m able to consistently get participants for all meetings. My source code is identical for both authentication methods. The only difference is the method to generate the bearer token in the HTTP request.
Yes, my code for these endpoints is identical, but results are inconsistent using server-to-server OAuth. I’m calling the report/meetings/meeting.uuid/participants endpoint for every meeting that takes place at my company in a given day, Daily meeting list size is in the hundreds. Each time I run my program, I get a different total number of daily meeting participants using server-to-server OAuth. Results are consistent using JWT. This process needs to run on a daily basis.
This is currently under escalation review. Sharing the ticket number here for other developer and Developer Advocates who may encounter someone experiencing the same behavior (ZSEE-85355).
@gianni.zoom Following this as I think this is related to the force migration from JWT to the server-to-server tokens. With server-to-server tokens both expiring after an hour and invaliding past tokens when requesting a new one this issue manifests frequently as a race condition. Two requests coming in to our service, asking for a token around the same time will invalidate the others token before it even has a chance to use it. Either let these tokens live indefinitely (not ideal) or; keep the one hour expiry but let accounts request them as needed without invalidating previous ones. Also of note, it’s not useful to have up to three “indexed” tokens here. Are we expected to coordinate between all our incoming requests who gets which indexed token? Global mutex between all our backend servers that may be trying to use these tokens?!?
For key rotation, we use a shared database that acts as a synchronization primitive to decide on a race condition winner process that renews the token for the inactive slot well in advance, then swaps that slot into active use for everyone in the same environment. This means you need 2 slots per environment, so we ended up creating multiple duplicate applications so we could have 4 slots to allocate among 2 environments.
Appreciate your input, but the developer here is experiencing this error occasionally with a valid token nowhere near expiration while sending one request at a time.