Understanding Zoom RTMS Behavior and Its Constraints

If you implement RTMS correctly, you will get real-time audio, video, transcripts, and event metadata with very low latency. That’s the upside, and it’s substantial.

The part that surprises teams is that starting RTMS depends on a number of user-related reasons – how the Zoom meeting was set up, host permissions, RTMS app settings, and more.

This article is meant to help PMs, CTOs, and engineers forecast the real user experience of your RTMS app. If you are looking for a primer on RTMS, check out What is Zoom RTMS? Throughout this article, we’ll refer to end users simply as users.

Before diving into the conditions surrounding RTMS, let’s define some common terms.

• Participant - An individual who is present in the Zoom meeting.
• Host - The manager of the meeting. Hosts do not need to be present in the meeting. When in the meeting, the host can take various actions that others can not such as mute participants, admit participants from the waiting room, and allow in-meeting apps to run.
• App Owner - The participant who brings and starts the Zoom app.
• Zoom Admin - The individual responsible for organization-wide settings. This person is typically a member of the IT team at the organization that they are the admin for.

A quick way to tell if RTMS will work for a meeting

The table below shows the primary conditions that determine whether RTMS will start, pause, stop, or fail in a given meeting. Each column represents a specific requirement or constraint. Each row represents a real-world meeting scenario.

This table is intended to give you a brief overview of when RTMS will get meeting data and when it will not. If a particular scenario matters to your use case, you can jump to the linked section below for a deeper explanation or check out the appendix to see how each scenario is created.

RTMS has a few prerequisites that must be satisfied before the meeting begins, like the host’s organization settings and supported Zoom client versions for both meeting host and app owner. If those prerequisites aren’t met other conditions become irrelevant and RTMS can’t start. Once those pre-meeting conditions are met, RTMS behavior is controlled by in-meeting factors such as host approval and host presence, which determine whether RTMS starts, pauses, resumes, or stops.

How the host organization impacts RTMS

RTMS behavior is governed primarily by the meeting’s host organization. The host organization is the Zoom workplace that is hosting the meeting

If the host’s Zoom organization admin keeps RTMS enabled, RTMS can work regardless of participant settings. If the host organization disables RTMS, no participant setting, OAuth scope, or API call can enable it. This host-centric model is intentional and shapes when RTMS works reliably in real-world meetings.

How to set RTMS as zoom admin

Throughout the rest of this article, nearly every instance of RTMS starting or not starting maps back to this host-governed model.

What this means for your users

Your users may find that RTMS is allowed to capture meeting data in some environments, and isn’t allowed to receive meeting data in other environments, even when the app relying on RTMS is built correctly. That inconsistency usually maps to one thing: Are users joining meetings hosted by their own organization, or by external organizations?

• Internal-first meetings (sales enablement, support, recruiting inside one organization) tend to be a good fit, because the host of the meeting tends to be someone within your Zoom organization.
• External meetings (users joining customer meetings, partner meetings, community calls) will have more variability when using RTMS alone, because the host of the meeting could be someone outside your Zoom organization, and Zoom RTMS may not be set up in someone else’s Zoom organization.

Note: If the hosting Zoom organization is a free Zoom account, RTMS should work, as it’s enabled by default and cannot be turned off.

Zoom client version requirements

The host and the user of the app that relies on RTMS must both have a Zoom client version that is at least version 6.5.5+. If the host is on an unsupported or outdated client, RTMS will not start even if admin settings are correct.

Some client-related failures are effectively silent from the end-user point of view. There is no messaging when RTMS is unavailable for a particular meeting. This is why, if you decide to use RTMS, you should consider how the handle your app not receiving data after the request to start the app has been sent.

Host presence and meeting start authority

Whether the host is present affects RTMS in two related but distinct ways: whether the meeting itself can start, and whether RTMS is allowed to begin streaming.

In Zoom, users can set meetings to start with or without the host. In the event that the meeting is only allowed to start with the host and the host never joins, there is no meeting to pull data from.

Host presence is required for RTMS only when host approval is required. In meetings where host approval is required, the host must be present in the meeting to grant RTMS access. If the meeting has started without the host and host approval is required, RTMS cannot begin streaming. In this case, the app owner must wait for the host to join and then resend the RTMS request. When host approval is not required, the host does not need to be present for RTMS to start so long as the meeting has started.

RTMS app auto-start behavior

Auto-start allows RTMS to begin without the app owner manually triggering the app, but it only helps in specific scenarios.

If host approval is required, auto-start does not bypass it. RTMS will wait for approval even if the meeting is already running.

Auto-start can enable RTMS to start regardless of if the host joins when:

• the meeting is allowed to start without the host, and
• host approval is not required to start RTMS.

Auto-start can be particularly useful if the host wants to record the meeting using an app that relies on RTMS, they cannot attend the meeting, and they have auto-start on for their RTMS app and the meeting is set to start regardless of whether the host joins.

Host approval and data requests

Some meetings require the host to approve apps that request real-time meeting content.

When enabled:

• RTMS remains paused until approval is granted
• if approval never comes, RTMS may never start

Approval applies to the entire request. There is no way for the host to approve sharing specific pieces of data requested such as transcript or audio.

If your app requests audio, video, and transcript, and the host is uncomfortable sharing any part of that request, the host denies the request and RTMS produces no data.

Requesting more media types increases the likelihood of denial simply because there are more pieces of data that the host may object to sharing.

RTMS app owner presence

In some cases, RTMS can start and continue without the app owner actively participating.

The app owner’s presence matters in cases where the app owner joins the meeting and then leaves the meeting. In that case RTMS stops when the app owner leaves the meeting.

If the app owner never joins the meeting and the app starts using auto-start then the app will run without the app owner’s presence.

Breakout rooms

As of January 2026, RTMS does not capture breakout room content.

When a meeting enters breakout rooms, RTMS stops streaming for the duration of those sessions. RTMS may resume once the meeting returns to the main room, but any content that occurred inside breakout rooms is unavailable.

If your product depends on capturing breakout sessions, such as workshops, training sessions, or interview loops, RTMS will not work.

Participant organization settings

Participant organization settings do not affect RTMS behavior. If a participant does not want to be recorded they should leave the meeting when RTMS is enabled to avoid having their data captured. This design ensures that real-time access policies are applied consistently across the meeting rather than negotiated participant by participant.

How RTMS can pause, stop, and resume during a meeting

RTMS access is not decided only at the start of a meeting. Even after streaming begins, the host and host organization can still change or revoke access. As a result, based on host actions, host transitions, or changes in sharing permissions, RTMS can pause, stop, or resume during a meeting.

For product design, host approval should be treated as a condition that can change over time. Therefore, products using RTMS should consider how to capture data or alert users that the meeting data is no longer being captured when host approval changes.

In addition to approval at startup, both the host and the RTMS app owner can stop sharing real-time meeting content at any point during the meeting. When this happens, RTMS may pause or stop mid-meeting, and may resume later if sharing is re-enabled.

What can stop RTMS during a meeting

To users, the changes listed above can result in RTMS suddenly stopping or restarting. This behavior is expected and reflects the host’s ongoing control over real-time access.

RTMS sessions cannot be resumed after a disconnect. Any data not captured during interruptions is permanently lost. Your app must wait for a new meeting.rtms_started event before reconnecting.

The scenarios above are not edge cases. They are the result of the host-governed permission model that RTMS operates under.

A planning framework for PMs and CTOs

Before committing to RTMS as your only real-time path, decide which world you live in:

World A: Mostly internal or controlled meetings
You can standardize admin settings, client versions, and approval policy. RTMS can deliver a consistently strong user experience.

World B: Many external meetings with unknown hosts
Expect variability. RTMS can still be valuable, but your product experience needs:

• Clear messaging (e.g. “This meeting doesn’t allow RTMS”)
• Other capture methods to fall back to. Recall.ai supports RTMS as well as other capture methods so that you can access meeting data regardless of video conferencing platform or edge case.

In many cases, layering approaches can ensure that you get data no matter the use case.

Conclusion

If you’re interested in learning more about Zoom RTMS, you can check out our article on Zoom RTMS or chat with a member of our team. If you want to learn more about all of the options available for capturing meeting data, you may be interested in Recall.ai’s Meeting Bot API or Desktop Recording SDK.