OBF Token Retry for "Authorized User Not In Meeting" Triggers Repeated Host Email Notifications

Meeting SDK
1

Meeting SDK Type and Version

Linux Meeting SDK (Native C++), version 6.7.5

Description

We operate a meeting bot platform that joins Zoom meetings using OBF tokens. When the authorized user hasn’t joined the meeting yet, the SDK returns MEETING_FAIL_AUTHORIZED_USER_NOT_INMEETING.

Following Zoom’s documentation and guidelines in this related thread, we have implemented retry logic that re-attempts the join after a delay.

However, this creates two problems:

Problem 1 - Host email spam: Each join attempt triggers an email notification to the meeting host (e.g. “Someone is waiting to join your meeting”), even though the bot never actually enters the meeting. Over several minutes of retrying, the host receives multiple unwanted emails.

Problem 2 - Spurious MeetingEnded signal: As described in the related thread above, the SDK fires a MeetingEnded event immediately after the AUTHORIZED_USER_NOT_INMEETING failure.

This is indistinguishable from a genuine host-ended meeting, making it unsafe to continue retrying. We have worked around this by suppressing MeetingEnded events that occur during an active OBF retry window using a state guard and timeout-based circuit breaker, but this is fragile and adds significant complexity.

The combination of these two issues means there is currently no clean way to handle the common scenario where a bot is ready before the authorized user.

We would like to know:

1. Is there a way to check whether the authorized user is in the meeting before attempting the join? An SDK method to verify user presence without triggering the full join flow (and the associated host email) would resolve both problems.

2. Could Zoom suppress the host notification for OBF join attempts that fail with AUTHORIZED_USER_NOT_INMEETING? The bot never enters the meeting, so notifying the host is unnecessary.

3. Could the SDK provide a distinct event for the spurious MeetingEnded fired after AUTHORIZED_USER_NOT_INMEETING, separate from a genuine host-ended meeting?

This would eliminate the need for the suppression workaround. Error MEETING_FAIL_AUTHORIZED_USER_NOT_INMEETING followed by a spurious MeetingEnded event.

The errors themselves are handled - the issue is the side-effects (host emails and ambiguous meeting-ended signal).

Troubleshooting Routes -

  • Reviewed the Updates to Meeting SDK Authorization FAQ and Meeting SDK auth docs - no guidance on this scenario
  • Reviewed the Zoom Linux SDK sample apps (meetingsdk-linux-raw-recording-sample, meetingsdk-headless-linux-sample) - no OBF retry patterns present
  • Implemented retry logic as advised by Zoom Engineering in the related * thread - Implemented MeetingEnded suppression during OBF retry using state guard + timeout circuit breaker

How To Reproduce

  1. Authentication: JWT auth for SDK init, OBF token for meeting join (JoinParam.onBehalfToken)
  2. Start a Zoom meeting but do NOT have the authorized user (the user associated with the OBF token) join yet
  3. Have the SDK bot attempt to join with the OBF token
  4. SDK returns MEETING_FAIL_AUTHORIZED_USER_NOT_INMEETING followed immediately by MeetingEnded
  5. Handle the error, wait ~30 seconds, retry the join
  6. Meeting host receives an email notification for each attempt
  7. Repeat until the authorized user joins - host receives multiple emails over the retry window
1 Like
2

Hi @Yusuf2 , last I heard they’re aware of this issue and will fix it in the coming days.

Best,
Noah

1 Like
3

@Yusuf2 sorry didn’t read your entire post. They’ll fix the email spam issue, but not sure about the “Spurious Meeting Ended” issue.

4

Thanks for the info @noah.duncan , really appreciate it!

Good to know they are aware of the issue and we’ll keep an eye out for the fix. Curious to hear from Zoom if there are any plans to correct the MeetingEnded behaviour.

Thanks again for the heads up.

5

Hello @Yusuf2 thank you for reporting this and providing the details and reproductions steps.

As @noah.duncan mentioned above our engineering team is aware of the two issues addressed - the multiple email notifications for each attempt as well as the MeetingEnded event being triggered while the meeting is active. As we work towards providing solutions here we will update our FAQs and docs accordingly. In addition, please see below to some of your follow up questions

1. Is there a way to check whether the authorized user is in the meeting before attempting the join? An SDK method to verify user presence without triggering the full join flow (and the associated host email) would resolve both problems.

Currently, the SDK does not provide a direct method to verify host presence without initiating the join flow. You can query for active participants or use the meeting status webhook to determine whether the host has joined. This avoids triggering the join attempt that causes the waiting room email. I’ve shared this feedback with the team in order to provide a presence check method.

2. Could Zoom suppress the host notification for OBF join attempts that fail with AUTHORIZED_USER_NOT_INMEETING? The bot never enters the meeting, so notifying the host is unnecessary.

This is a valid point and the failed OBF join attempts don’t need to generate waiting room or join notifications unless it’s an error. This has been logged internally as part of the same investigation.

3. Could the SDK provide a distinct event for the spurious MeetingEnded fired after AUTHORIZED_USER_NOT_INMEETING, separate from a genuine host-ended meeting?

Yes. Engineering is evaluating whether to introduce a distinct event or error code to differentiate between a true meeting end and an early termination caused by AUTHORIZED_USER_NOT_INMEETING

Please stay tuned for additional updates

1 Like