How to manage ZAK tokens for bots

API and Webhooks
1
• POST /v2/users — create/manage bot-pool users
• GET /v2/users/{userId}/token?type=zak&ttl= — generate ZAK
• Meeting SDK (Web Component) ZoomMtg.join() — joining with zak param

Description
We’re building a meeting bot solution that should also support Zoom meetings with required participant authentication. My understanding is that to handle it, we need to create and maintain a pool of Zoom users and use ZAK tokens generated for these users via Zoom API (server to server OAuth App) to feed them into bots (SDK). Please confirm or describe alternatives.

I’ve run a small proof-of-concept:

  • One test user (under a Business master account)
  • ZAK generated with ttl=172800 (48 h)
  • The same ZAK successfully joined six concurrent meetings (all as participant, not host) in separate browser instances.

Before we finalise the architecture I’d like to double-check a few things that the docs and forum posts haven’t made fully explicit:

  1. Concurrent-meetings limit per ZAK / per user
    My test reached six meetings with one ZAK. Is there an official max-concurrency limit (per user-ID) when all sessions are participants?*If there is none, what hidden risks exist in running dozens or hundreds of parallel meetings with a single user versus maintaining a larger user pool?

  2. Does generating a new ZAK invalidate the previous one?
    The thread “If I create a ZAK invalidate the previous one?” (couldn’t link it) implies “no” but ends inconclusively.In a high-throughput scenario we may re-issue a ZAK for a busy user before the older token has been consumed by another bot. Will that older token still work?

  3. Impact of ZAK expiry while the bot is already in the meeting
    My understanding is that the ZAK is checked only at join time. After the SDK session is established, subsequent expiry or regeneration should not eject the participant. Can Zoom confirm that a live Meeting-SDK session will remain connected even if the original ZAK reaches exp or a new one is minted?

  4. Name & avatar personalisation with ZAK
    In the Web SDK I can still pass userName, and the meeting shows that custom name, while the avatar is loaded from the Zoom account profile. Is this the expected behaviour (i.e., userName overrides profile name but avatar remains account-based) or am I relying on an implementation detail that could change?

  5. Is there recommendation on the Zoom tier we should use to host the users? Is Zoom Pro enough?(ISV partner sounds a bit overkill if we can live with limited number of users)

  6. Assuming we would use autoCreate option to programatically add users based on demand using an email pool from our dedicated Google Workspace, can we obtain ZAK token right after the user is created? Is there any limitation or requirement for users created this way?

  • autoCreate - This action is for Enterprise customers with a managed domain. autoCreate creates an email login type for users.

If there are alternative, recommended approaches for authenticated-join bots (e.g. a way to bypass per-user constraints without the ISV custCreate route) please let me know.

Thanks in advance for clarifications!

2

Hi Kamil,

We have customers running Zoom bots with ZAK tokens at scale, so I can help out with some of these questions!

  1. Concurrent-meetings limit per ZAK / per user
    We haven’t observed any concurrency limits with ZAK tokens, you should be able to use one single Zoom service account/user to generate all the ZAK’s for all meetings. You don’t need to worry about maintaining multiple service accounts to provide ZAK tokens to different meetings.

  2. Does generating a new ZAK invalidate the previous one?
    Generating a new ZAK shouldn’t invalidate the previously-generated ZAK tokens.

  3. Impact of ZAK expiry while the bot is already in the meeting
    You’re correct that the ZAK is checked at join time. If the ZAK expires after the bot has joined the meeting, it will not be ejected from the meeting. However, if your bot loses its connection with the meeting partway through and tries to rejoin, you’ll need to generate a fresh ZAK token for it to be able to join successfully.

  4. Name & avatar personalisation with ZAK
    The behavior where the bot’s name is configurable while the bot’s profile picture is inherited from the underlying Zoom account has been consistent since we’ve started using ZAK tokens over two years ago, so I wouldn’t expect this to change any time soon.

Since a single service account user should be sufficient for your use case, I don’t think questions 5 and 6 will be relevant for you anymore.

Another option that you can consider would be the Recall.ai API. It’s a unified API that lets you send meeting bots to video conferencing platforms (like Zoom) to capture the audio and video in real-time. We also support providing ZAK tokens to Zoom bots. I’ll link our documentation for ZAK tokens here in case it’s helpful.

Let me know if you have any questions!

3

Thanks Amanda. That’s super helpful. :heart_eyes:

Ideally, I would love to hear some confirmation from Zoom support/engineers as well.