Please enable RTMS for my account

Hello, kindly enable RTMS for my account as well…. thank you!

Hello @WimKerkhoff please follow the steps highlighted on this post RTMS Account Access - How To Get Started and we can get a trial account set up for you.

Hello,

I’d like to request RTMS enablement for my account.

App Name: ScribeBear
Production Client ID: nR7rnfGmR7yopEGDgstzDg
App Type: User-managed General App

The app is fully built and deployed — Zoom Apps SDK is working (config authorized, getMeetingContext returns data), webhook is validated, and event subscriptions for RTMS events (rtms_started, rtms_stopped, rtms_interrupted) are configured. However, when calling zoomSdk.startRTMS(), I receive error 40316 (“API hasn’t passed marketplace verification”).

Use case: Real-time meeting transcription using OpenAI Whisper, with AI-generated meeting summaries delivered via Telegram.

I have all required scopes configured (rtms:read:rtms_started, rtms:read:rtms_stopped, rtms:read:rtms_interrupted, rtms:read:rtms_concurrency_near_limit, rtms:read:rtms_concurrency_limited, zoomapp:inmeeting, zoomapp:inwebinar + ZCC Voice RTMS scopes).

Could you please enable RTMS for my account? Thank you!

Hi @elisa.zoom
Could you please enable RTMS for my account ? what is the right process to get it enabled ? I’ve already filled the form but waiting for the enablement of rtms on my account. Thanks in advance.

Hi @Amit11 and @Amir8
RTMS has been enabled in your account

can you DM me to help me enable RTMS

Thanks

Thanks @elisa.zoom for your timely support.

hi @elisa.zoom can you DM me to help me enable RTMS too?
Thanks so much

Hi @elisa.zoom

Even though you have enabled RTMS for my account but I am still getting below error. And I don’t see the option Allow apps to access meeting content setting in the Settings page of the Zoom web portal.

I am using server to server oauth application and not seeing any option in the zoom account settings.

Could you please help ?

curl https://api.zoom.us/v2/live_meetings/83183372122/rtms_app/status
–request PATCH
–header ‘Content-Type: application/json’
–header ‘Authorization: Bearer xxxx’
–data ‘{
“action”: “start”,
“settings”: {
“client_id”: “xxxxxx”
}
}’<2028>
{“code”:13262,“message”:“The app ‘wzBokINqQxiBLJ548ka2RA’ is not authorized to access meeting content. Please add it in the Allow apps to access meeting content setting in the Settings page of the Zoom web portal.”}

Hi @Amit11 - RTMS scopes are only available for user-level apps. In Marketplace, that corresponds to selecting a “General App” when creating the app.

You shouldn’t need to significantly change your overall approach. The key difference is just the app type. Once it is set up as a General App, the RTMS scopes will be available.

Even though it is a user-level app, admins can still deploy it across the entire account or to specific groups, so you can still achieve workspace-wide enablement similar to your current setup.

Hi @JenBrissman

Thanks for your quick reply !

I would like to explain my use case and check whether the proposed approach is feasible, or if there is a better way to achieve it.

I am building an application that uses RTMS to capture live meeting transcripts. The requirement is to capture transcripts only for a specific set of users, not for all meetings across the organization.

I have already tested this using a General user-managed OAuth app, and it works as expected. However, I would like to explore whether this can be implemented using a single account-level application, without requiring individual user authorization.

My proposed approach is as follows:

  • Create an account-level OAuth app with the required RTMS-related scopes.

  • Define a user group containing only the users whose meetings need to be captured

  • Assign the application to this group so that it can access meetings for those users

  • Avoid requiring each user to install/authorize the app individually

  • Have an admin authorize the app once, and securely store the tokens (e.g., in a vault/secret store)

  • Use these admin tokens in the backend service to:

    • Start RTMS sessions

    • Connect to the RTMS WebSocket for transcript streaming

Could you please confirm:

  1. Whether this approach is supported, particularly assigning an account-level app to a specific group of users for RTMS access

  2. Whether it is possible to avoid per-user OAuth authorization entirely

  3. If there are any limitations or recommended best practices for this use case

  4. How to create account managed app with RTMS scope ?. General oauth app with admin managed didn’t listed RTMS start/stop webhook events and couldn’t see scopes as well.

If this approach is not supported, I would appreciate guidance on the recommended architecture to capture transcripts for a subset of users in an organization.

Thank you for your help.

Hello @JenBrissman
Could you please provide your input ? Thanks

Hello @JenBrissman @elisa.zoom
Could you please share your inputs on the above queries ?

Hi @Amit11 There is no RTMS scope for admin level / account level general app.

  1. Create a user level general app with RTMS scope and assign the application to the group of users.
  2. Use the user OAuth to get the access token and refresh token. Alternatively you can also configure autostart for this application.

Hi @Amit11

Adding to what @chunsiong.zoom said here:

The main constraint is that RTMS is only supported on user-level (General) apps today. Because of that, a single account-level app with only admin authorization (and no per-user OAuth) isn’t supported. Assigning an account-level app to a group won’t grant RTMS access for those users.

What works today is still centered around a user-level app, but you can structure it in a way that feels mostly centralized.

At a high level:

  • You need a General (user-level) app with RTMS scopes, installed for just the users you care about (can be deployed via admin to a group)
  • There is still a one-time user OAuth step, but after that you can store tokens and run everything from your backend

A great way to make this low-friction is to use a Zoom Apps surface app (we always recommend this path. Surface apps with RTMS is a common use case):

  • The surface app runs in the meeting (even in guest mode initially)
  • The first time the user opens it, OAuth completes and you obtain a user token
  • After that, the frontend doesn’t really need to stay authenticated, your backend can take over

From there, a clean way to structure things is to split responsibilities:

  • App B (user-level, RTMS app)
    • Has RTMS scopes
    • Is authorized by the target users
    • Represents the app that actually “owns” RTMS
  • App A (can be account-level)
    • Handles backend orchestration (listing meetings, deciding when to start RTMS, etc.)
    • Uses REST APIs

For apps under the same account, App A can start RTMS on behalf of App B by specifying App B’s client ID in the request. So you still get centralized control, even though RTMS itself is tied to a user-level app:

One important note: the account-level “install to group” behavior you referenced was designed primarily for surface apps, which is why that pattern fits well here, and it works right now.

If you want to avoid surface apps entirely, we are working on a non-interactive / bulk OAuth flow to support this exact scenario. There’s an early beta, but there are still gaps (like tracking which users are authorized and handling newly added users after the initial install), so it’s not fully ready yet.

TL;DR:

  • Fully avoiding user authorization → not possible today
  • Best current approach → user-level RTMS app + group deployment + optional surface app for first-time auth
  • You can still centralize control using an App A / App B pattern mentioned above within the same account

Thanks @JenBrissman for the detailed response.