Find the exact module, copy the working request shape, and move from product workflow to API call without getting buried in the tree.
Write the workflow in plain language. We will turn it into a GPT-ready brief you can use to generate requests, module order, and starter payloads.
Streams gives each live feed a stable operational identity above the transport endpoint. Use it when an SRT or RTMP server exists, but your team also needs a durable stream name, role, stream ID, optional host binding, and saved inspection data.
This is the record operators use to follow one feed across monitoring, playback, troubleshooting, and automation. If a listener is restarted or a server object is reused, the stream identity stays the same.
role_name defines whether the feed is a publisher or receiver.stream_id gives the feed a durable identifier for routing and operations.host optionally ties the stream to a known remote source.audio_settings and stream_meta_data store inspection results for later reuse.Publisher on an SRT listener. Use this when a known encoder publishes into an SRT ingest point and you want a consistent stream record for dashboards and troubleshooting.
{
"name": "Main stage publisher",
"role_name": "publisher",
"stream_id": "publisher/main-stage/srt-main",
"entity_id": "680400000000000000000001",
"module_name": "MODULE_SRT_SERVERS",
"active": true
}
Receiver with host binding. Use this when a return feed should be associated with a specific remote host, such as a contribution partner or field unit.
{
"name": "Remote return receiver",
"role_name": "receiver",
"stream_id": "receiver/main-stage/return-feed",
"host": "198.51.100.24",
"entity_id": "680400000000000000000001",
"module_name": "MODULE_SRT_SERVERS",
"active": true
}
Publisher on an RTMP server. Use this for RTMP contribution or origin workflows where the published feed needs a stable operational identity.
{
"name": "RTMP primary publish",
"role_name": "publisher",
"stream_id": "studio/live/program",
"entity_id": "680500000000000000000001",
"module_name": "MODULE_RTMP_SERVERS",
"active": true
}
If operators trigger actions from vMix, the create, start, and stop methods also include vMix Script examples.
Create a stream record as soon as a contribution path is assigned. Use that record in dashboards, incident notes, and operator tools instead of referring only to the underlying server object.
After a source connects, run getStreamInfo to inspect the real feed. Save the resulting audio layout or other media details in audio_settings or stream_meta_data with create, update, or setStreamInfo. This avoids rediscovering channel order, codec details, or other source-specific settings each time the feed returns.
Use start to activate the stream, then getStreamInfo when a player, monitoring probe, or downstream workflow needs the concrete SRT or RTMP URL for the current session.
Creates a new stream row in Callaba Engine.
The stream object does not replace an SRT server or RTMP server. It sits on top of one of those entities and keeps the stream-facing identity stable: name, role, stream id, optional host, and any saved audio metadata the team should not have to rediscover later.
If your team triggers provisioning from an operator workflow, the example set below also includes vMix Script tabs for the same create call.
Start with the preset that matches the transport backing the stream. Publisher and receiver rows on top of SRT listeners behave differently in practice, and RTMP-backed rows normally carry a different stream id convention again.
Use this when one managed SRT listener serves multiple named publisher flows and you want those flows to stay visible as first-class rows that operators can recognize quickly.
Use this when routed or pulled traffic should keep a stable receiver-facing identity instead of only being implied by transport state.
Use this when channel naming, layout, or per-track meaning should live with the stream object instead of being rediscovered every time.
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.