Question
People commonly ask on the Zoom Developer Forum:
We’re building a Zoom meeting bot solution that needs to join meetings with participant authentication enabled. From the docs, it looks like we need to:
-
Create/manage bot-pool users (
POST /v2/users
) -
Generate ZAK tokens (
GET /v2/users/{userId}/token?type=zak&ttl=
) -
Join the meeting with the Meeting SDK (
ZoomMtg.join()
) using thezak
parameter
A few clarifications are still unclear before finalizing architecture:
-
Concurrency: Is there a max number of meetings a single user/ZAK can join as a participant?
-
Multiple tokens: Does issuing a new ZAK invalidate older ones?
-
Expiry: If a ZAK expires while the bot is in the meeting, does it get kicked?
-
Identity: Can the bot’s display name and avatar be customized, or are they fixed by the account profile?
-
Accounts: Do we need many managed users, or will a single service account suffice?
Answer
Here’s what we’ve seen in production with customers running Zoom bots at scale using ZAK tokens:
Concurrency
- There is no observed concurrency limit for ZAK tokens.
- A single Zoom service account can generate all the ZAK tokens your bots need.
- You do not need to maintain a large pool of service accounts just to support multiple meetings.
Multiple Tokens
- Generating a new ZAK does not invalidate older ones.
- Multiple valid ZAKs can exist for the same user at the same time.
Expiry Behavior
- ZAK expiry is enforced only at join time.
- Once a bot is in a meeting, it will stay connected even if the ZAK expires or a new one is generated.
- If the bot disconnects and needs to rejoin, it must request a fresh ZAK.
Identity (Name & Avatar)
- The display name can be overridden at join time (e.g., via
userName
in the Web SDK). - The avatar is pulled from the Zoom account profile. That behavior has been consistent for years and is unlikely to change.
Accounts
- Because one service account can handle many concurrent meetings, you don’t need to manage a pool of users.
- For most use cases, a single Pro or Business account user is enough.
tldr; One Zoom service account can support many authenticated bots at once. Generate ZAK tokens as needed, don’t worry about concurrency limits, and remember that ZAK is only validated at join time.
Zoom Developer Forum Examples
Some examples of this question are: