@alroya You have two valid (from Zoom’s perspective) tokens simultaneously (either via separate token_index values or different applications), but only one of them is in active use by your application at a given time. If you have a shared database, it can decide which one is in active use. You renew and perform maintenance on the token that is inactive, then swap it into active use for your application. Other processes can continue using the previous active token because it’s still valid from Zoom’s perspective, so they don’t need to notice the new token immediately. I’ve written more about this concept of a key rotation strategy in other threads.
@elisa.zoom I was getting a HTTP 400 response code with the body {"reason":"Invalid request : Maximum group number limit exceeded","error":"invalid_request"} whenever I raised the token_index above 0, but I’d invested 2 months into support ticket #14947692 and decided it was no longer worth the effort to troubleshoot further when anyone can just create multiple duplicate applications without Zoom’s prior approval (which is what the first backend engineer’s reply to that ticket recommended doing anyway) for functionality that should be available by default. Don’t worry about it; we needed 4 valid tokens anyway to share across 2 environments, and I don’t anticipate switching back to using token_index and coming up with a persuasive “genuine business impacting use case” at this point to make that happen.