Live Publish

Overview

Live Publish takes one source and sends it to up to 10 destinations at once. You can go live now or schedule a stream up to 60 days ahead. You can run it from the dashboard (Live) or with POST /v1/live.

• Sources: a public URL (HLS .m3u8, MPEG-DASH .mpd, MP4/MOV/WebM/MKV/FLV/TS files, RTMP/RTMPS, RTSP/RTSPS, SRT) or a video from your media library.
• Connected destinations: YouTube, Facebook Pages and Twitch. Relaycast creates the broadcast through each platform's API, sets the title, gets the ingest URL and ends the broadcast when you stop.
• Custom RTMP destinations: every other live platform (Instagram, X, TikTok, LinkedIn, Kick, Facebook profiles and groups, or any RTMP/RTMPS server). You create the live in the platform's own tool and paste its server URL and stream key.

Each destination is independent. If one platform drops or rejects the stream, the others keep going.

Destinations

Stream keys are encrypted at rest. They never appear in API responses or logs. The response shows only the server address (server).

Sources

Source URLs must point to public hosts. Private, loopback and link-local addresses are rejected, and so are URLs with a username or password in them. The dashboard's Check source button looks at the URL before you go live. It reports the format, live or VOD, the qualities and codecs found, and whether the server supports byte ranges.

The source must be reachable when the stream starts. Live sources (HLS/DASH live, RTMP, RTSP, SRT) are reconnected automatically up to 5 times if they drop.

Video and audio

Audio is copied if it is AAC and the video is passed through. Otherwise it is encoded to AAC 160 kbps / 48 kHz. Sources without audio get a silent track, because YouTube, Facebook and Twitch require one.

The stream's stats report what was found and what was done: videoCodec, audioCodec, width, height, fps, encoding (copy or 720p/1080p), bitrateKbps, speed and restarts.

Lifecycle

Each destination has its own status (pending, connecting, live, ended, failed), error and watchUrl (YouTube, Facebook and Twitch). A stream with one failed destination keeps going on the others.

A stream ends when:

• the source ends (files without loop, VOD playlists, a live source that stops and doesn't come back),
• you call Stop (it takes effect within about 5 seconds),
• it reaches maxDurationMinutes (at most 720), or
• the project runs out of live minutes.

On YouTube the broadcast is moved to complete, and on Facebook the live video is ended. Twitch goes offline when the stream stops.

You get an in-app notification when a stream goes live, ends, or fails.

Limits

Minutes are counted per stream, not per destination: one hour sent to 5 platforms uses 60 minutes. Check usage with GET /v1/live/usage.

Example

curl -X POST https://social-publish-api.onrender.com/v1/live \
  -H "x-access-key: $RELAYCAST_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "title": "Product launch",
    "description": "Live from the studio",
    "source": { "type": "url", "url": "https://cdn.example.com/launch/index.m3u8" },
    "destinations": [
      { "accountId": "8a7b6c5d-4e3f-4a1b-9c8d-7e6f5a4b3c2d", "options": { "privacy": "public" } },
      { "accountId": "1b2c3d4e-5f6a-4b7c-8d9e-0f1a2b3c4d5e" },
      { "type": "custom", "preset": "instagram", "url": "rtmps://edgetee-upload-xx.fbcdn.net:443/rtmp/", "streamKey": "1789…?s_bl=1&s_ow=10" }
    ],
    "startNow": true
  }'

See the API reference for every field.

Self-hosting notes

• The worker runs ffmpeg (bundled through ffmpeg-static; set FFMPEG_PATH to use your own build).
• Each running stream is one ffmpeg process. Passthrough uses very little CPU. Re-encoding to 720p needs about 1 vCPU per stream, and 1080p needs about 2. Small free instances (such as Render's free 0.1 CPU) can only do passthrough reliably.
• LIVE_CONCURRENCY (default 2) is how many streams one worker runs at a time. Add workers to run more.
• Twitch needs TWITCH_CLIENT_ID and TWITCH_CLIENT_SECRET. See Twitch.