Streams
Use Streams to create named publisher and receiver connections for SRT or RTMP endpoints. Each record gives applications a stable connection identity and reusable media settings.
Choose this whenEach publisher or receiver needs its own identity on an existing SRT or RTMP server.
Use another module whenUse SRT Servers or RTMP Servers to create the ingest endpoint itself.
/api/streams/createBefore you start
All methods require a valid x-access-token. Create the related SRT or RTMP server first and keep the server and stream identifiers consistent.
What you can do
create,update,getAll,getCount, andgetByIdmanage connection records.startandstopcontrol supported stream lifecycle actions.getStreamInforeads connection information.setStreamInfoapplies supported stream information.removedeletes a stream record.
Example workflow
- Create a publisher record for the intended SRT or RTMP server.
- Assign its role,
stream_id, host details, and required audio settings. - Give the generated connection details to the publisher.
- Use
getStreamInfoduring setup and troubleshooting.
Common use cases
- Issue a dedicated connection to each remote camera team.
- Separate publisher and receiver identities on a shared ingest server.
- Store audio-channel settings for repeatable contribution feeds.
Limits and troubleshooting
Duplicate or mismatched stream identifiers can prevent the expected connection. A stream record depends on its parent server and cannot make an unreachable publisher healthy. Do not expose credentials or unrestricted connection details outside the intended participant.
Next steps
Connect the publisher or receiver, then inspect the parent SRT or RTMP server's runtime statistics.
Register and operate a reusable stream source
Create the stream identity and connection settings once, start it when required, and read its current stream information for downstream automation.
- Create the streamSave the reviewed source identity and connection contract.
POST /api/streams/create - Start the sourceStart it before attaching downstream modules.
POST /api/streams/start - Read stream informationUse current stream metadata in your control workflow.
POST /api/streams/getStreamInfo
A successful create response confirms configuration, not media health. Start the resource, then verify its runtime statistics before sending production traffic.
Create a managed stream identity above an SRT or RTMP transport resource. The stream stores its name, publisher or receiver role, stream id, optional host, linked entity, and optional audio metadata.
A vMix Script example is available when an operator workflow must provision the stream.
Request examples
Choose the preset for an SRT publisher, SRT receiver, RTMP publisher, or stream with a saved audio layout.
Common use cases
- Name multiple publisher streams that share one SRT listener.
- Keep a stable receiver identity for routed or pulled traffic.
- Store channel names, layouts, or track meaning with the stream.
Use this when one SRT listener hosts a named publisher stream that operators should treat as a first-class object.
Use this when a receiver-side or returned feed should keep its own stream identity and optional host binding.
Use this when the backing transport entity is an RTMP server rather than an SRT listener.
Use this when channel layout and naming should be stored with the stream row after inspection.
Dashboard label: Name.
Human-facing name of the saved stream row.
Dashboard label: Role.
Typical product values include publisher, receiver, pusher, and puller.
Stable stream identifier stored above the backing transport entity.
Optional host binding used when the stream identity should stay tied to a concrete remote peer.
Identifier of the backing transport-side entity, for example an SRT server or RTMP server.
Module family behind the stream row. In practice this is most often MODULE_SRT_SERVERS or MODULE_RTMP_SERVERS.
Optional saved audio layout with named tracks and channels.
Dashboard label: Enable once created.
Controls whether the stream row should be active right after provisioning.
Identifiers and the saved stream identity fields.
Reference back to the transport object that owns or serves the stream.
Saved inspection output, codec notes, and optional channel mapping metadata.
Runtime flag and backend-managed timestamps.
Successful stream model responses expose success: true as a virtual field.