Live streaming API

A live streaming API with the stream key behind its own permission

Create a stream for every class, customer or event from your own code, issue its stream key under a separate permission, and hand viewers signed playback URLs. The same live system as the dashboard, driven by a versioned REST API.

Start free trialAPI reference
Three calls from nothing to a playable stream
# 1 · Create a stream (scope live_streams:write)
POST /v2/live-streams
Authorization: Bearer <api-key>
Idempotency-Key: 6f1c2a90-weekly-briefing
{ "title": "Thursday product briefing" }

# 2 · Issue the stream key (scope live_ingest:write)
POST /v2/live-streams/{liveStreamId}/ingest:rotate-key
→ { "protocol": "rtmp", "ingestUrl": "…", "streamKey": "…" }
#   the key is returned once; later reads show only a hint

# 3 · Hand viewers a playback source (scope live_streams:read)
GET /v2/live-streams/{liveStreamId}/playback
→ { "hlsEmbedUrl": "…", "hlsDirectUrl": "…", "webrtc": null }

The basics

What is a live streaming API?

A live streaming API lets your software create and manage live streams instead of a person clicking through a dashboard. Your platform creates a stream when an event is booked, gives the presenter an ingest address and stream key, and gives viewers a playback URL, all without anyone copying values between screens.

DynTube’s live streaming API is part of its v2 management API, described by a generated OpenAPI 3.1 document. Streams created through it run on DynTube’s new live system and play through the same player and embed as streams created in the dashboard.

The resources

What can you control through the live streaming API?

Each item is an operation the published contract defines, named as the contract names it.

Live streams/v2/live-streams
List, create, read and update streams, and archive one when it is finished. Lists are paginated and can be filtered by status, project or search text.
Ingest, with its own permissioningest · ingest:rotate-key
Read the ingest address and protocol (RTMP, RTMPS or SRT) at any time. The stream key itself is issued or rotated only by a separate call that needs the narrower live_ingest:write scope, and it is returned once.
Playbackplayback · embed
Fetch signed HLS URLs for embeds and for direct or third-party players, or the embed code for the DynTube player. Where WebRTC playback has been enabled for your account by arrangement and the stream has it switched on, the response also carries a short-lived WebRTC source.
Schedules/v2/live-stream-schedules
Create one-time or recurring schedules that play a list of your videos as a live stream, with repeat, shuffle and loop options and an explicit time zone.
Private linksprivate-links
Create, rotate and revoke private links that give a chosen audience access to a stream without listing it publicly.
Recordingcreate options
Opt in to recording into a project you choose where your plan includes it.

Built for production code

How does the API keep automation safe?

The parts of the contract that matter once real events depend on your integration.

A first integration

How do you automate your first live event?

Five steps from an API key to a stream your platform created by itself.

  1. 01

    Create two API keys

    One with live_streams:write and live_streams:read for your application, and one with live_ingest:write for the service that hands keys to presenters.

  2. 02

    Create the stream when the event is booked

    POST to /v2/live-streams with a title and an Idempotency-Key derived from your booking, so a retry never duplicates it.

  3. 03

    Issue the stream key to the presenter

    Call ingest:rotate-key once, pass the ingest URL and key to the presenter’s encoder, and do not store the key anywhere you would not store a password.

  4. 04

    Give viewers the playback source

    Fetch playback or embed for the stream and place it on the page your viewers already sign in to.

  5. 05

    Archive it afterwards

    Archive the stream when the event is over, so lists stay clean and the stream cannot be used again by mistake.

Questions

Live streaming API questions

Direct answers, each within the published contract.

Which ingest protocols does the live streaming API support?

The ingest endpoint reports one of three protocols: RTMP, RTMPS or SRT. Your encoder publishes to the ingest URL with the stream key issued by the rotate-key call. Publishing from a browser over WebRTC is not offered; WebRTC is used for viewer playback only.

How does authentication work?

Each request sends an API key as a bearer token in the Authorization header. Scopes are enforced per route: live_streams:read and live_streams:write for streams and playback, and the narrower live_ingest:write for issuing or rotating stream keys.

Can I get WebRTC playback URLs from the API?

Yes, where WebRTC playback has been enabled for your account by arrangement and the stream was created with it switched on. The playback response then includes a WebRTC source with a short-lived token. Otherwise that field is empty and you play the HLS URLs, which are always present.

Is there an older version of the API?

Yes. The v1 live streaming guides remain the written procedures for existing integrations and carry their own compatibility notice. New integrations should start from the v2 OpenAPI document.

Are there limits on how many streams I can create?

Yes. Live streams, WebRTC streams and schedules are plan limits, checked when you create them. Confirm the limits of your plan before building an integration that creates streams in bulk.

Let your platform create the stream

Start a trial, create an API key, and have your code create, broadcast to and archive one test stream.

Start free trialAPI reference