Zoom Developer Forum

How to manage ZAK Tokens for Zoom bots

Updated at:
September 21, 2025
Written By:
Maggie Veltri

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 the zak 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:

Written By:
Maggie Veltri