> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Simulcast a webinar with RTMP egress

> Push a scheduled video room's live output to YouTube Live, LinkedIn Live, Vimeo, or any custom RTMP ingest. Start up to five simultaneous destinations in one egress, stop a single stream by id, and re-attach when a destination drops.

# Simulcast a webinar with RTMP egress

Your webinar already runs on Orbit; RTMP egress is how the same broadcast also
goes out on the platforms where your audience actually is. An RTMP egress takes
the scheduled room's composite video and pushes it, live, to an RTMP ingest that
you own the credentials for: YouTube Live, LinkedIn Live, a corporate Vimeo
account, or any self-hosted RTMP server.

This guide walks the full lifecycle: provision the room, start one egress with
several simultaneous destinations, stop it, and recover when a destination
drops mid-show.

## What RTMP egress is

An egress is one outbound live push attached to one scheduled video room. Orbit
renders the room composite once (the same layout a recording would use) and
streams it as a single adaptive-bitrate RTMP push to every destination you list
on that egress. Each egress has its own id, so you can run several egresses on
one room and stop any one of them without touching the others or the room
itself.

Two related surfaces are easy to confuse with it:

* **Recording** writes the composite to a file in your storage bucket. It can
  run next to an RTMP egress on the same room; stopping one never stops the
  other. See [Bring your own storage for recordings](/guides/video-recording-byo-storage).
* **HLS/DASH playback** is pull-based adaptive streaming for viewers Orbit
  serves. RTMP egress is the opposite direction: a push out to a third-party
  ingest you authenticate against, for audiences on platforms you do not
  operate.

An egress only pushes while the room is live, and nothing about it places a
call or message; it is pure video out.

## Prerequisites

Before the first request below, you need:

1. **A scheduled video room.** The egress endpoints take the scheduled room id
   in the path. If you do not have one yet, follow
   [Registration-gated video webinars](/guides/video-webinars) up to the point
   where the room exists, then come back here.
2. **A broadcast destination for each platform.** On each platform's live
   encoder setup page, copy the ingest URL and the stream key. YouTube gives
   you `rtmps://a.rtmp.youtube.com/live2` plus a key; LinkedIn and Vimeo hand
   you the equivalent pair. The URL must start with `rtmp://` or `rtmps://`
   and must include the ingest's app path (the `/live2` part), not just the
   host.
3. **An API key with the `video:write` scope**, held by a user with the owner
   or admin role. Starting a public stream is deliberately restricted to the
   host tier; other roles receive a 403.
4. **A recording consent receipt, if your organization requires one.** An
   RTMP egress leaves a persistent recording on the destination platform, so
   tenants in two-party-consent jurisdictions must pass
   `recording_consent_receipt_id` on the start call, exactly as the in-app
   recording paths do.

Keep stream keys secret. Orbit stores and echoes only the ingest URL, never
the key, and the same discipline applies on your side: keys belong in your
secrets store, not in client-side code or shared documents. Rotate them on the
platform if one leaks; a revoked key is the most common reason a push fails.

## Provision the scheduled room

RTMP egress never creates a room; it attaches to one. Create and schedule the
room as usual (see [Registration-gated video webinars](/guides/video-webinars))
and note its id, for example `room_9f2c` below. The room does not need to be
live when you start the egress; the push begins carrying content as soon as
the room session is producing video.

## Start an egress

`POST /api/v1/video/rooms-scheduled/{id}/egress/rtmp` starts one egress. The
body splits each destination into `rtmp_url` and `stream_key` so the key is a
clearly labelled secret field:

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/video/rooms-scheduled/room_9f2c/egress/rtmp" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rtmp_url": "rtmps://a.rtmp.youtube.com/live2",
    "stream_key": "xxxx-xxxx-xxxx-xxxx",
    "layout": "speaker"
  }'
```

`layout` picks the composite layout the destinations receive: `grid`,
`speaker`, `single-speaker`, `picture-in-picture`, `sidebar`, `highlight`, or
`gallery`. It defaults to `speaker`, which is usually right for a webinar
because it foregrounds the presenter.

The response returns the egress id plus every destination URL **without** its
key, so you can display them safely:

```json theme={null}
{
  "data": {
    "egress_id": "eg_7k2m",
    "rtmp_url": "rtmps://a.rtmp.youtube.com/live2"
  }
}
```

Store the `egress_id`; it is the handle for the matching stop call later.

### Simulcast to several platforms in one egress

A simulcast does not need one egress per platform. Pass the first destination
as `rtmp_url` / `stream_key` and the rest in `additional_destinations`; the
composite is rendered once and fanned out to all of them inside the same
egress, so three platforms cost one render, not three. You may add up to four
additional destinations, five simultaneous destinations per egress in total,
and one egress may not list the same URL-plus-key destination twice.

The worked example below takes one scheduled webinar to YouTube Live,
LinkedIn Live, and a corporate Vimeo account at the same time:

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/video/rooms-scheduled/room_9f2c/egress/rtmp" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rtmp_url": "rtmps://a.rtmp.youtube.com/live2",
    "stream_key": "yb-key-xxxxxxxx",
    "layout": "speaker",
    "additional_destinations": [
      {
        "rtmp_url": "rtmp://live-upload.linkedin.com/live",
        "stream_key": "li-key-xxxxxxxx"
      },
      {
        "rtmp_url": "rtmps://rtmp.cloud.vimeo.com/app",
        "stream_key": "vm-key-xxxxxxxx"
      }
    ]
  }'
```

Each destination shows a moment of encoder latency before the platform marks
the stream live; that is normal ingest behaviour, not a fault in the push.

If you need more than five destinations, start a second egress on the same
room; egresses are independent and each stops by its own id. You can also give
an egress a backup destination (`backup_rtmp_url` + `backup_stream_key`,
supplied together): if the primary ingest refuses the push at launch, the
egress starts against the backup instead of failing.

## Lifecycle: stop one egress

`DELETE /api/v1/video/rooms-scheduled/{id}/egress/rtmp/{egressId}` stops exactly
that egress, including its whole fan-out when it simulcasts. The call is
idempotent, and it leaves every other egress, the room, and any recording
running untouched:

```bash theme={null}
curl -X DELETE "https://api.orbit.devotel.io/api/v1/video/rooms-scheduled/room_9f2c/egress/rtmp/eg_7k2m" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

The platform side settles within seconds; YouTube and LinkedIn mark the
broadcast ended and archive what they received up to that point.

Across the room's own lifecycle, egress follows the session: it pushes while
the room session runs, and when the session ends Orbit stops any egress still
running on it. The egress id from a finished session is not reusable; to
simulcast the next session of the same scheduled room, start a fresh egress
with the same call.

## When an egress stops unintentionally

Three failures cover most incidents, and each has the same recovery: start a
new egress with corrected destinations.

1. **The destination refuses the push at launch.** Usually a mistyped or
   revoked stream key, or an ingest that was never armed on the platform side.
   The start call fails rather than leaving a half-live stream; if you
   supplied `backup_rtmp_url` / `backup_stream_key`, the egress transparently
   starts against the backup and your broadcast survives.
2. **The destination ends the stream mid-show.** The platform rotated the key,
   an admin on the platform stopped the live event, or the account hit a
   platform-side limit. The egress reports the failed destination and stops
   pushing to it; verify the key on the platform, then POST a new egress to
   re-attach. Minutes you missed are not backfilled; live means live.
3. **The request was rejected before launch.** A 422 at start is almost always
   one of these: the URL does not begin with `rtmp://` or `rtmps://`; the URL
   is a bare host with no ingest app path (`rtmps://a.rtmp.youtube.com/live2`
   is valid, `rtmps://youtube.com` is not); a backup URL was given without its
   key or vice versa; or two listed destinations are the same URL and key.
   A 403 means the caller lacks the owner/admin role or the `video:write`
   scope; a 503 means Orbit Media is not configured for the tenant, which your
   administrator enables.

In all three cases the room itself is unaffected: attendees in the room keep
their session, and a recording keeps recording.

## Monitoring and history

Three surfaces tell you what your egresses are doing:

* **The start response** gives you the `egress_id` and the destination URLs
  (keys stripped), which is enough to drive a "live on" banner.
* **The room's settings** carry the active egress list: for each running
  egress, its id, ingest URL, start time, and who started it. Keys never
  appear there.
* **The session history** records the outcome after the room ends. Each
  finished session's record includes its media metrics and egress status, so
  "did the LinkedIn leg actually run" is answerable after the fact; see
  [Video room history](/guides/video-room-history) for reading that
  trajectory.

For viewer-side truth (concurrent viewers, watch time, chat), read the
platform's own dashboard; Orbit reports the health of the push, the platform
reports the audience. [Video engagement
analytics](/guides/video-engagement-analytics) covers the in-room side of the
same event.

## Related guides

* [Registration-gated video webinars](/guides/video-webinars) — the room this
  guide attaches to.
* [Video room history](/guides/video-room-history) — per-session records,
  including what the egress did.
* [Video engagement analytics](/guides/video-engagement-analytics) — the
  in-room audience side of a webinar.
* [WHEP guest player](/guides/whep-guest-player) — embed low-latency viewing
  for guests who stay on your own site instead of a social platform.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.