# RTMS behavior differences between App Auto-Start vs manually starting RTMS via API **URL:** \ **Category:** Realtime Media Streams\ **Tags:** webhooks, api\ **Created:** [January 9, 2026, 10:22pm UTC](https://devforum.zoom.us/t/rtms-behavior-differences-between-app-auto-start-vs-manually-starting-rtms-via-api/140368 "2026-01-09T22:22:47Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![amanda-recallai](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/amanda-recallai/32/44747_2.png) [@amanda-recallai](https://devforum.zoom.us/u/amanda-recallai)\ **Post date:** [January 14, 2026, 1:37am UTC](https://devforum.zoom.us/t/rtms-behavior-differences-between-app-auto-start-vs-manually-starting-rtms-via-api/140368/3 "2026-01-14T01:37:05Z")
Hi @Bill3, This is usually a timing/consent issue: Zoom notes that [“If there’s no one in the meeting to approve the app, the RTMS session cannot start”](https://devforum.zoom.us/t/can-i-receive-streams-without-joining-the-meeting-host-participant-and-permission-scenarios-explained/131485), so if your webhook fires and you call `start` before the host (or an authorized approver) is actually in the meeting, the request won’t result in `meeting.rtms_started`. A practical fix is to delay or retry the PATCH until you see the host join (and treat early joins as “not ready”), using signals like [the `meeting.participant_jbh_waiting` event (“Joined Before Host”)](https://devforum.zoom.us/t/webhook-participant-notifications-and-join-before-host/13153) or `meeting.participant_joined`, and log the PATCH HTTP status/body so you can catch non-2xx responses you might be ignoring. On the base URL changing it shouldn’t affect the host-first vs participant-first behavior. --- _[View the full topic](https://devforum.zoom.us/t/rtms-behavior-differences-between-app-auto-start-vs-manually-starting-rtms-via-api/140368)._