Hi Yoon,
Thank you for the quick review.
Before we consider this closed, I would like to clarify our use case, as I do not believe OBF, ZAK, or RTMS fully address it. This capability is currently part of a live production service, so we are hoping to find a workable and compliant path forward.
Meeting BaaS provides recording and transcription bots that join meetings with the explicit authorization of our customers. In many cases, our customer is an invited participant in a meeting hosted by an external Zoom organization. They are not the host, and neither they nor the host are part of our Zoom account.
The bot clearly identifies itself and joins only with the customer’s consent, in the same way that a human guest would join using a meeting number and passcode. Anonymous SDK join is what allowed the bot to attend these externally hosted meetings, and this flow was working until around July 7, 2026.
Regarding OBF tokens, Zoom’s documentation indicates that the token must be generated for a user who has authorized our application through OAuth and is actively present in the meeting. Zoom also verifies that user’s presence when the bot joins.
This creates two major limitations for our use case. First, the bot cannot join before the authorizing user, which means it cannot wait in the waiting room or reliably capture the meeting from the beginning. Second, the token ties the bot to a specific Zoom user who must already be present. This does not solve the broader issue of joining a meeting hosted by an external organization that our customer does not control.
ZAK appears to have a similar limitation because it requires a Zoom user that we control, and that user would not normally be present in an externally hosted customer meeting.
RTMS is useful when our customer is the meeting host. However, it must be enabled by the host’s account administrator and depends on the host’s account configuration and licensing. Our customer is often only an invited participant, so they cannot enable RTMS for another organization’s Zoom account.
The common issue is that these alternatives require an authenticated relationship with, or control over, the meeting host’s account. Our use case is specifically for meetings where our customer is an invited participant rather than the host. Anonymous join was the mechanism that allowed us to support that scenario.
Given that this change affects an existing production B2B service, could you please help us with one of the following options?
-
Approve the Anonymous Join Exception for APP ID cXrItkaFRn-ykWP1zvNJEQ, Meeting BaaS.
-
Provide a temporary, time limited exception while we migrate, along with guidance on a supported approach for externally hosted meetings where the authorizing user is a non host participant.
-
Escalate this use case to the Meeting SDK product team for further review.
We want to remain fully compliant with Zoom’s requirements. We simply need a supported solution that covers recording and transcription for meetings where the customer is an invited participant rather than the host.
Thank you again for your help.