Meeting SDK joinMeeting returns "fail" after multiple joins — is there rate limiting on SDK join attempts?

[Jenova]

We’re developing a React Native app using @zoom/meetingsdk-react-native that allows users to join Zoom meetings via the Meeting SDK. During our initial testing and development phase, we joined
20+ different meetings in a relatively short period using the same SDK key/secret pair. All joins were successful.

After that testing burst, every subsequent joinMeeting call now fails immediately with Error: fail — the error is thrown by the native bridge before any network connection is attempted. This
affects all meetings, including the developer’s own Personal Meeting Room.

What we’ve ruled out:

• Meeting password: We tested with and without the password parameter (empty string). Same result.
• ZAK token: Valid ZAK token is being passed. Joins were working with ZAK before the failures started. Removing ZAK doesn’t help either.
• Meeting number: Confirmed valid meeting numbers. Tried multiple different meetings.
• SDK initialization: SDK initializes successfully (ready state), the failure only occurs on joinMeeting.
• Code changes: We reverted to the exact same SDK call configuration that was working previously — joinMeeting({ meetingNumber, userName, password: “”, zoomAccessToken: zakToken }). Same
  failure.
• App restart / device restart: No change.

Our SDK call:

const statusCode = await zoom.joinMeeting({
meetingNumber: “…”,
userName: “…”,
password: “”,
zoomAccessToken: zakToken, // valid ZAK from /users/me/token?type=zak
})

Environment:

• @zoom/meetingsdk-react-native (latest)
• React Native 0.81 / Expo 54
• iOS (physical device)
• Meeting SDK app type (not OAuth app)

Questions:

1. Is there a rate limit on the number of joinMeeting calls per hour/day for a given SDK key/secret pair?
2. If so, what are the limits, and is there documentation on this? We couldn’t find any mention of join rate limits in the SDK docs.
3. Is there a cooldown period, or does the limit reset on a fixed schedule (hourly, daily)?
4. Is there a way to check current rate limit status via API?

Any guidance would be appreciated. The immediate Error: fail from the native bridge with no error code or descriptive message makes this very difficult to debug from our side.

[gianni.zoom (Gianni)]

@Jenova

• Is there a rate limit on the number of joinMeeting calls per hour/day for a given SDK key/secret pair?
• If so, what are the limits, and is there documentation on this? We couldn’t find any mention of join rate limits in the SDK docs.
• Is there a cooldown period, or does the limit reset on a fixed schedule (hourly, daily)?
• Is there a way to check current rate limit status via API?

@Jenova yes there is. We have a disclaimer under the Linux guidance, but should have it across platform types:

I’m waiting to hear back from the MSDK PM about publicly documenting and sharing in more detail around the rate limits. What is your current account plan? I can disclose that rate limit is lowest on the free account.

[Jenova]

Thank you so much for your input! Yes, it appears that upgrading to Pro has resolved the issue for now for my testing. Note, this is not for bot usage, although the system is implemented in much the same way as a bot would be implemented. These will be initially about 1k users joining public recovery meetings on a nightly basis via a zoom sdk enabled app. The rate of joining can be quite high at peak hours of the day/evening. Please let me know if our users may run into a rate limit, and if so I will obtain permier support and request an exception. Note also, some users will be joining with their own account ZAK token, while others - being anonymous as per all recovery fellowships - will be using essentially a bot account.

[gianni.zoom (Gianni)]

No problem @Jenova ! And thank you for the additional context.

@Jenova

Note, this is not for bot usage, although the system is implemented in much the same way as a bot would be implemented. These will be initially about 1k users joining public recovery meetings on a nightly basis via a zoom sdk enabled app. The rate of joining can be quite high at peak hours of the day/evening.

There are auth per second quota limits for each type of account type. I recommend throttling join attempts with a few seconds delay. Example, join 100 users, wait 3 seconds, and then proceed with next group of users. If it’s not possible to control this, request an exception.

@Jenova

Note also, some users will be joining with their own account ZAK token, while others - being anonymous as per all recovery fellowships - will be using essentially a bot account.

For bot-like use cases, OBF will need to be used. Please see the guidance here: FAQ - Updates to Meeting SDK authorization

[Jenova]

(post deleted by author)

[Jenova]

(post deleted by author)

[Jenova]

(post deleted by author)

[Jenova]

Ok, so what I have read, in order to join a meeting outside a users own account an OBF token must be used, a ZAK will not be sufficient.

User + OBF → join external meetings = WORKS
User + ZAK → join external meetings = DOES NOT WORK???

Did I read “FAQ - Updates to Meeting SDK authorization” correctly? After 3/2/26 the ONLY way for the SDK to allow entry into an external public zoom meeting is for a person in the meeting w/ a ZAK to allow others to join via an OBF?

In our apps specific case:

1. We are authenticating our Pro account with Zoom oAuth and then generating ZAK tokens for users to join with, so many users will be joining meetings as our authenticated Zoom Pro account.

2. Our app also has the ability to allow a user to oAuth with Zoom using their own zoom account and thus use a ZAK token to join external meetings as themselves.

I’m assuming case 2 will always work, otherwise the SDK is pretty much useless.

Case 1 should also work as well since a ZAK is present and identifies a legitimate user (our Pro account) - BUT will experience rate limiting on ZAK generation API calls and possibly on concurrent meeting attendance.

This is what is confusing me:

The ““FAQ - Updates to Meeting SDK authorization” first sentence says ”Beginning March 2, 2026, Zoom requires the use of an OBF token for MSDK apps joining meetings hosted by external accounts.”. Leading me to believe that the SDK can only join external meetings with an OBF token. That is what that sentence says.

Then it goes on to show:

Start or join a Zoom meeting or webinar as a Zoom user	JWT + ZAK token	The ZAK token is associated with a Zoom user.

but mentions NOTHING of internal vs external meetings - which totally contradicts the first sentence of the document and leading to a reasonable belief that a ZAK will work for both internal and external meetings, as the other stipulations are very clear in bold lettering regarding their internal vs external meeting requirements for JWT and OBF tokens:

Join a Zoom meeting or webinar outside the app owner’s account associated with a Zoom user account	JWT + OBF token	On behalf of (OBF) tokens can only be used for joining. They require an associated user with a ZAK token, and that user must already be in the meeting for the join to succeed.

I just noticed at the top of this forum post it states:

” Beginning March 2, 2026, apps joining meetings outside their account must be authorized. Meet this requirement by using either OBF or ZAK tokens , or RTMS”

So my assumption is that our app’s method of allowing users to join external meetings using a ZAK will work just fine..

Thank you for explaining,
Jenova

[Jenova]

This is what Claude says about the above:

Your post is well-reasoned and your final conclusion is correct. Here’s my analysis:

Your reading is right — the FAQ is genuinely contradictory

You correctly identified the tension:

1. Opening sentence implies OBF is the only way to join external meetings

2. The table row for ZAK says nothing about internal vs external — it just says “Start or join a Zoom meeting or webinar as a Zoom user”

3. The forum banner resolves it: “OBF or ZAK tokens”

The distinction the FAQ is trying to make (poorly) is between:

• A person joining (ZAK) — works for any meeting, internal or external, because there’s a real authenticated Zoom user

• An app/bot joining externally (OBF) — for automated participants without a user identity already in the meeting

Your two cases

Case 2 (user OAuth → their own ZAK): No question, this will always work. A real user joining as themselves.

Case 1 (System Pro account → ZAK shared across users): This is the riskier one. The ZAK is valid and represents a real Zoom user, so it should satisfy the authorization requirement. But as
you noted, the practical concerns are:

• Rate limiting on ZAK generation API calls

• Concurrent meeting limits — many users appearing as the same Zoom account simultaneously could trigger Zoom’s abuse detection

Your post is clear and well-argued. I’d just suggest you explicitly ask Zoom to confirm Case 1 won’t be flagged as bot-like behavior given the shared-identity pattern.

…….

I’m sorry I ever mentioned the word ‘bot’ as this app is NOT A BOT. These are real people trying to enter publicly posted recovery meetings.

Please, can I get some clarification on this? I reached out two days ago to Premium Support regarding an exclusion but I’ve heard nothing back. This is a legitimate Use-Case scenario of the SDK, or at least it should be. We have 10,000+ public zoom meetings that we have assembled in our DB to make finding and attending recovery meetings easily available to the public. We are a FREE app. We are NOT creating bots! We are a non-profit origination connecting people to recovery via Zoom, honestly one of the most noble uses of the Zoom platform. Please, give us some technical clarification and work with us.