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.
The SRT routes section describes the endpoints used to create and manage route objects that take an incoming source and send it to an outgoing SRT destination in Callaba Engine.
In practice, this is the API layer you use when you want a persistent source-to-destination routing object that can be started, stopped, queried, and updated over time.
The route model is easiest to read in four practical layers: what the route is called, where it receives the signal, where it should hand that signal off next, and whether that handoff should already be live when the route is created.
SRT routes are not one flat request shape. The payload changes depending on the source choice, destination choice, and whether the route needs the extra SRT controls that only matter once reliability or latency becomes a real production concern.
SRT listen-port source, an SRT Stream URL (srt://) source, and a UDP source for route input.SRT listen-port destination and an SRT Output URL (srt://) destination for route output.The create payload has three layers: the route itself, the source side, and the destination side. The exact request shape depends on the kind of handoff you want to support in production.
For example, a route built from URL-based source and destination uses input_stream_url and output_stream_url. A listen-based route instead uses the listen-port objects plus the advanced SRT settings that help when stability and latency need closer control.
These examples are organized around real routing decisions, so teams can copy the shape that matches the way they want traffic to move instead of reverse-engineering one oversized generic payload.
Use this pattern when Callaba should listen for an incoming SRT contribution on a local port and then forward it to an outgoing SRT destination.
{
"router_name": "Route from listen port to SRT output",
"input": {
"input_type": "INPUT_TYPE_SRT_LISTEN",
"input_stream_listen_port": {
"port": 2035,
"transport": "udp"
},
"input_settings": {
"host": "0.0.0.0",
"latency": 500,
"rcvlatency": 200,
"fc": 25600,
"rcvbuf": 12288000,
"inputbw": 750000,
"oheadbw": 25
},
"module_name": "MODULE_SRT_ROUTERS"
},
"output": {
"output_type": "OUTPUT_TYPE_SRT_URL",
"output_stream_url": "srt://127.0.0.1:1935",
"output_settings": {
"host": "0.0.0.0",
"mode": "listener",
"latency": 500,
"rcvlatency": 200,
"fc": 25600,
"sndbuf": 12288000,
"rcvbuf": 12288000,
"inputbw": 750000,
"oheadbw": 25,
"groupconnect": "yes",
"groupminstabletimeo": 60,
"conntimeo": 3000
},
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}
Use this pattern when the route should pull from an upstream SRT URL and expose the outgoing side as a local listener destination.
{
"router_name": "Route from SRT URL to listen port",
"input": {
"input_type": "INPUT_TYPE_SRT_URL",
"input_stream_url": "srt://upstream.example.com:2034?mode=caller",
"input_settings": {
"rcvbuf": 48234496
},
"module_name": "MODULE_SRT_ROUTERS"
},
"output": {
"output_type": "OUTPUT_TYPE_SRT_LISTEN",
"output_stream_listen_port": {
"port": 3035,
"transport": "udp"
},
"output_settings": {
"host": "0.0.0.0",
"mode": "listener",
"latency": 500,
"rcvlatency": 200,
"fc": 25600,
"sndbuf": 12288000,
"rcvbuf": 12288000,
"inputbw": 750000,
"oheadbw": 25
},
"module_name": "MODULE_SRT_ROUTERS"
},
"active": false
}
These scenarios connect SRT routes to the rest of the product model. They are useful when you are designing a pipeline, not just calling /api/srt-routes/create in isolation.
Create an SRT route first when you want the ingest side and the outbound SRT handoff to stay stable while the downstream restream job changes independently. This is a good fit when your input source is fixed, but your social destinations or transcoding settings change often.
MODULE_SRT_ROUTERS -> MODULE_RESTREAMUse an SRT route when you want to normalize or isolate the source before it reaches the recording module. This is especially helpful when the route should stay persistent, but recordings are created only for selected events or schedules.
MODULE_SRT_ROUTERS -> MODULE_RECORDINGSRoutes are useful when one team owns ingest and another team owns downstream consumers. Instead of exposing the original source directly to every module, you expose a route output and treat it as the shared handoff point.
Creates a new SRT route resource in Callaba Engine.
The current Swagger definition exposes this method as POST /api/srt-routes/create with an application/json request body that contains the route name, source configuration, destination configuration, and active flag.
The exact nested fields depend on how the route should receive the signal and how it should hand that signal off. The descriptions below are written so a team can choose the route shape that best matches the production path they actually want to run.
In live product tests, the create response returns the created route on the top level together with success: true, but the route's input and output arrays are still empty immediately after creation. Use getById if you need the expanded source and destination objects.
Authentication uses the dashboard-issued JWT token in the x-access-token header.
vMix note: use Create SRT route from vMix only when the production needs to provision a route on demand. For most live buttons and shortcuts, teams create the route ahead of time and then trigger Start or Stop instead.
These examples are useful when you are designing a real pipeline and need to decide why the route exists, not only what the payload looks like.
Use this pattern when the ingest side should stay fixed, but the downstream restream job may be recreated, restarted, or pointed at different social destinations over time. The route output becomes the stable upstream that the restream module reads from.
MODULE_SRT_ROUTERS -> MODULE_RESTREAMUse this pattern when you want scheduled or event-specific recordings to attach to a stable route output instead of binding directly to the original contribution source every time.
MODULE_SRT_ROUTERS -> MODULE_RECORDINGSIf you are trying to mirror familiar routing scenarios in your own integration, use the scenario-specific request examples below. Each preset has its own request block with language tabs and copy support.
The route listens on a local SRT port and owns the incoming contribution handoff.
Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.
Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.
Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.
The route pulls from an upstream SRT URL instead of waiting on a local listening port.
Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.
Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.
Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.
The route reads from a UDP source URL when the upstream side is already exposed as UDP.
Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.
Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.
Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.
Dashboard label: Route name.
Characters: A-Z, a-z, 0-9, and -.
Dashboard group: SRT/UDP route source.
The route source type. In the dashboard, the SRT option is shown as SRT Stream URL (srt://). The current example uses INPUT_TYPE_SRT_URL.
Dashboard label: SRT Stream URL (srt://).
Connect to the specified URL address and try to pull the stream. The current example uses a listener URL: srt://0.0.0.0:2034?mode=listener.
Dashboard label: Receiver buffer size.
This is an optional advanced SRT input setting. The dashboard tooltip says the default receiver buffer size is 12058624 bytes and the recommended value is 48234496 bytes. Live route tests confirm the API accepts this field and returns it from getById when it is set.
Input module name. For SRT routes the dashboard and Swagger example use MODULE_SRT_ROUTERS.
Dashboard group: SRT route destination.
Dashboard label: Stream destination.
In the dashboard, the SRT destination option is shown as SRT Output URL (srt://). The current example uses OUTPUT_TYPE_SRT_URL.
Dashboard label: Output Stream URL.
Specify the address of the streaming platform or the stream destination. The current example uses srt://0.0.0.0:2035.
Output module name. For SRT routes the dashboard and Swagger example use MODULE_SRT_ROUTERS.
Listen source preset: SRT Port.
When the route source is built from the dashboard's listen-port preset, the default port is 2035. This is the practical alternative to input.input_stream_url.
Dashboard label: SRT Listen Host.
The local IP address to bind. The dashboard tooltip explicitly calls out 0.0.0.0 for all interfaces and 127.0.0.1 for localhost-only binding. The default is 0.0.0.0.
Dashboard label: Latency.
Defines the maximum accepted transmission latency. The current dashboard default for route SRT settings is 500 ms.
Dashboard label: Receiver latency.
Minimum receiver buffering delay before the application gets the packet. The current dashboard default is 200 ms.
Dashboard label: Flow control window size.
Limits the maximum number of packets in flight. The current dashboard default is 25600 pkts.
Dashboard label: Input bandwidth.
Set this to the anticipated bitrate of the live stream. The current dashboard default is 750000 Byte/s.
Dashboard label: Recovery bandwidth.
Bandwidth overhead above the input bandwidth, in percent. The current dashboard default is 25%.
Dashboard label: Bandwidth limit.
The listen-source constants still define this field with a default of 0, even though the route Swagger example does not show it.
Dashboard label: Stream ID (optional).
Available on the SRT listen/source configuration block.
Dashboard label: Passphrase (optional).
Password for the encrypted transmission. The dashboard tooltip says it must be between 10 and 79 characters.
Listen destination preset: SRT Port.
When the route destination is built from the dashboard's listen-port preset, the default port is 3035. This is the practical alternative to output.output_stream_url.
Dashboard label: SRT Host.
In listener mode this is the local IP to bind, and in caller or rendezvous mode it is the remote IP to connect to. The current dashboard default is 0.0.0.0.
Dashboard label: Mode.
Possible values are caller, listener, or rendezvous. The current dashboard default is the second SRT mode option, which corresponds to the default route form shown in the UI.
Dashboard label: Latency.
Defines the maximum accepted transmission latency. The current dashboard default is 500 ms.
Dashboard label: Receiver latency.
Minimum receiver buffering delay before data is delivered to the receiving application. The current dashboard default is 200 ms.
Dashboard label: Flow control window size.
The current dashboard default is 25600 pkts.
Dashboard label: Sender Buffer Size.
The current dashboard default is 12288000 Bytes.
Dashboard label: Receiver Buffer Size.
The current dashboard default is 12288000 Bytes.
Dashboard label: Input bandwidth.
The current dashboard default is 750000 Byte/s.
Dashboard label: Recovery bandwidth.
The current dashboard default is 25%.
Dashboard label: Stream ID (optional).
The dashboard tooltip notes that it is settable in Caller mode only.
Dashboard label: Passphrase (optional).
Password for encrypted transmission. The dashboard tooltip says it must be between 10 and 79 characters.
Dashboard label: Enforced encryption.
Requires both connection parties to either use the same passphrase or both omit the passphrase. Otherwise the connection is rejected.
Dashboard label: Accept group connections.
When enabled on a listener socket, it allows this socket to accept group connections.
Dashboard label: Group stability timeout.
The current dashboard default is 60 ms.
Dashboard label: Connection timeout.
Applies to caller and rendezvous connection modes. The current dashboard default is 3000 ms.
Dashboard label: Enable once created.
Controls whether the route should be enabled immediately after creation.
Identifier of the newly created SRT route.
Convenience alias for the created route identifier. In live responses, id matches _id.
Name stored for the created route.
Immediately after creation, the live product returns an empty input array on the top level. Use getById to fetch expanded input objects.
Immediately after creation, the live product returns an empty output array on the top level. Use getById to fetch expanded output objects.
Whether the route is enabled after creation.
Creation timestamp returned by the live product.
The live product returns a boolean success flag together with the created route object. On success it is true.