SRT routes

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.

Route presets and request mapping

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.

  • Basic settings: route name and whether the route should be enabled immediately.
  • Source presets: the API supports at least an SRT listen-port source, an SRT Stream URL (srt://) source, and a UDP source for route input.
  • Destination presets: the API supports an SRT listen-port destination and an SRT Output URL (srt://) destination for route output.
  • Advanced settings: the visible fields depend on the selected source and destination type. SRT destination mode exposes the richest advanced block.

How the create payload is shaped

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.

Examples by preset

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.

Listen SRT port to SRT Output URL

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
}

SRT Stream URL to listen SRT port

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
}

Workflow examples

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.

Use a route as a stable upstream for Restream

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 path: MODULE_SRT_ROUTERS -> MODULE_RESTREAM
  • Why it helps: the route becomes the stable transport boundary, and the restream job can be recreated or restarted without changing the ingest side.
  • Typical shape: listen or pull with SRT route, then use the route output URL as the input to the restream module.

Use a route as a clean handoff into recording

Use 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 path: MODULE_SRT_ROUTERS -> MODULE_RECORDINGS
  • Why it helps: recording jobs can target the route output instead of binding directly to the original source every time.
  • Typical shape: route the incoming contribution into a listen port or SRT URL, then point the recording workflow at that route output.

Use a route to separate source ownership from downstream consumers

Routes 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.

  • Good fit for: shared infrastructure, QA environments, scheduled recordings, or multiple downstream consumers.
  • Operational benefit: the route can be started, stopped, or updated independently from the downstream jobs that read from it.
  • Documentation implication: if you are building a pipeline in stages, document the route output first and then attach Restream, Recording, or another route consumer afterward.
Create SRT route
Collapse
POST
/api/srt-routes/create

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.

Workflow-oriented use cases

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.

Put a stable route in front of Restream

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 chain: MODULE_SRT_ROUTERS -> MODULE_RESTREAM
  • Why teams use it: it separates source ownership from social distribution logic.
  • What to keep stable: route output URL or route listen port.

Put a stable route in front of Recording

Use 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 chain: MODULE_SRT_ROUTERS -> MODULE_RECORDINGS
  • Why teams use it: the route can stay persistent while recording jobs come and go.
  • Typical fit: recurring ingest, selective recording windows, or QA-friendly archive pipelines.

Preset-driven request shapes

If 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.

SRT listen port

The route listens on a local SRT port and owns the incoming contribution handoff.

SRT listen port to SRT listen port

Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.

SRT listen port to SRT listen port
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT listen port to SRT listen port",
"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_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,
"groupconnect": "yes",
"groupminstabletimeo": 60,
"conntimeo": 3000
},
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
SRT listen port to SRT Output URL

Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.

SRT listen port to SRT Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT listen port to SRT Output URL",
"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://destination.example.com: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
}'
SRT listen port to UDP Output URL

Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.

SRT listen port to UDP Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT listen port to UDP Output URL",
"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_UDP_URL",
"output_stream_url": "udp://destination.example.com:5000",
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
SRT Stream URL

The route pulls from an upstream SRT URL instead of waiting on a local listening port.

SRT Stream URL to SRT listen port

Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.

SRT Stream URL to SRT listen port
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT Stream URL to SRT 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,
"groupconnect": "yes",
"groupminstabletimeo": 60,
"conntimeo": 3000
},
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
SRT Stream URL to SRT Output URL

Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.

SRT Stream URL to SRT Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT Stream URL to SRT Output URL",
"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_URL",
"output_stream_url": "srt://destination.example.com: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
}'
SRT Stream URL to UDP Output URL

Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.

SRT Stream URL to UDP Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from SRT Stream URL to UDP Output URL",
"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_UDP_URL",
"output_stream_url": "udp://destination.example.com:5000",
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
UDP Stream URL

The route reads from a UDP source URL when the upstream side is already exposed as UDP.

UDP Stream URL to SRT listen port

Destination preset: SRT listen port. The route exposes a local SRT listening port for downstream consumers that connect later.

UDP Stream URL to SRT listen port
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from UDP Stream URL to SRT listen port",
"input": {
"input_type": "INPUT_TYPE_UDP_URL",
"input_stream_url": "udp://upstream.example.com:5000",
"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,
"groupconnect": "yes",
"groupminstabletimeo": 60,
"conntimeo": 3000
},
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
UDP Stream URL to SRT Output URL

Destination preset: SRT Output URL. The route pushes to a downstream SRT destination URL right away.

UDP Stream URL to SRT Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from UDP Stream URL to SRT Output URL",
"input": {
"input_type": "INPUT_TYPE_UDP_URL",
"input_stream_url": "udp://upstream.example.com:5000",
"module_name": "MODULE_SRT_ROUTERS"
},
"output": {
"output_type": "OUTPUT_TYPE_SRT_URL",
"output_stream_url": "srt://destination.example.com: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
}'
UDP Stream URL to UDP Output URL

Destination preset: UDP Output URL. The route hands off to a downstream UDP destination URL when the next hop expects UDP.

UDP Stream URL to UDP Output URL
curl --request POST \
--url http://localhost/api/srt-routes/create \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"router_name": "Route from UDP Stream URL to UDP Output URL",
"input": {
"input_type": "INPUT_TYPE_UDP_URL",
"input_stream_url": "udp://upstream.example.com:5000",
"module_name": "MODULE_SRT_ROUTERS"
},
"output": {
"output_type": "OUTPUT_TYPE_UDP_URL",
"output_stream_url": "udp://destination.example.com:5000",
"module_name": "MODULE_SRT_ROUTERS"
},
"active": true
}'
Request body parameters
Basic settings
router_name
string

Dashboard label: Route name.

Characters: A-Z, a-z, 0-9, and -.

Source
input.input_type
string

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.

input.input_stream_url
string

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.

Advanced source settings
input.input_settings.rcvbuf
integer

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.

Source
input.module_name
string

Input module name. For SRT routes the dashboard and Swagger example use MODULE_SRT_ROUTERS.

Destination
output.output_type
string

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.

output.output_stream_url
string

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
string

Output module name. For SRT routes the dashboard and Swagger example use MODULE_SRT_ROUTERS.

Source
input.input_stream_listen_port.port
integer

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.

Advanced source settings
input.input_settings.host
string

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.

input.input_settings.latency
integer

Dashboard label: Latency.

Defines the maximum accepted transmission latency. The current dashboard default for route SRT settings is 500 ms.

input.input_settings.rcvlatency
integer

Dashboard label: Receiver latency.

Minimum receiver buffering delay before the application gets the packet. The current dashboard default is 200 ms.

input.input_settings.fc
integer

Dashboard label: Flow control window size.

Limits the maximum number of packets in flight. The current dashboard default is 25600 pkts.

input.input_settings.inputbw
integer

Dashboard label: Input bandwidth.

Set this to the anticipated bitrate of the live stream. The current dashboard default is 750000 Byte/s.

input.input_settings.oheadbw
integer

Dashboard label: Recovery bandwidth.

Bandwidth overhead above the input bandwidth, in percent. The current dashboard default is 25%.

input.input_settings.maxbw
integer

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.

input.input_settings.streamid
string

Dashboard label: Stream ID (optional).

Available on the SRT listen/source configuration block.

input.input_settings.passphrase
string

Dashboard label: Passphrase (optional).

Password for the encrypted transmission. The dashboard tooltip says it must be between 10 and 79 characters.

Destination
output.output_stream_listen_port.port
integer

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.

Advanced destination settings
output.output_settings.host
string

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.

output.output_settings.mode
string

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.

output.output_settings.latency
integer

Dashboard label: Latency.

Defines the maximum accepted transmission latency. The current dashboard default is 500 ms.

output.output_settings.rcvlatency
integer

Dashboard label: Receiver latency.

Minimum receiver buffering delay before data is delivered to the receiving application. The current dashboard default is 200 ms.

output.output_settings.fc
integer

Dashboard label: Flow control window size.

The current dashboard default is 25600 pkts.

output.output_settings.sndbuf
integer

Dashboard label: Sender Buffer Size.

The current dashboard default is 12288000 Bytes.

output.output_settings.rcvbuf
integer

Dashboard label: Receiver Buffer Size.

The current dashboard default is 12288000 Bytes.

output.output_settings.inputbw
integer

Dashboard label: Input bandwidth.

The current dashboard default is 750000 Byte/s.

output.output_settings.oheadbw
integer

Dashboard label: Recovery bandwidth.

The current dashboard default is 25%.

output.output_settings.streamid
string

Dashboard label: Stream ID (optional).

The dashboard tooltip notes that it is settable in Caller mode only.

output.output_settings.passphrase
string

Dashboard label: Passphrase (optional).

Password for encrypted transmission. The dashboard tooltip says it must be between 10 and 79 characters.

output.output_settings.enforcedencryption
string

Dashboard label: Enforced encryption.

Requires both connection parties to either use the same passphrase or both omit the passphrase. Otherwise the connection is rejected.

output.output_settings.groupconnect
string

Dashboard label: Accept group connections.

When enabled on a listener socket, it allows this socket to accept group connections.

output.output_settings.groupminstabletimeo
integer

Dashboard label: Group stability timeout.

The current dashboard default is 60 ms.

output.output_settings.conntimeo
integer

Dashboard label: Connection timeout.

Applies to caller and rendezvous connection modes. The current dashboard default is 3000 ms.

Route state
active
boolean

Dashboard label: Enable once created.

Controls whether the route should be enabled immediately after creation.

Response
_id
string

Identifier of the newly created SRT route.

id
string

Convenience alias for the created route identifier. In live responses, id matches _id.

router_name
string

Name stored for the created route.

input
array

Immediately after creation, the live product returns an empty input array on the top level. Use getById to fetch expanded input objects.

output
array

Immediately after creation, the live product returns an empty output array on the top level. Use getById to fetch expanded output objects.

active
boolean

Whether the route is enabled after creation.

created
string

Creation timestamp returned by the live product.

success
boolean

The live product returns a boolean success flag together with the created route object. On success it is true.

Response: Create SRT route
JSON
{
"router_name": "Awesome SRT route",
"input": [],
"output": [],
"active": true,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"_id": "69c1de8e28c95839e0dffb74",
"__v": 0,
"id": "69c1de8e28c95839e0dffb74",
"success": true
}
Get all SRT routes
Expand
POST
/api/srt-routes/getAll

Returns a list of SRT routes visible to the authenticated user.

The current Swagger definition exposes this method as POST /api/srt-routes/getAll with a small pagination body. In live product tests, the response is a bare array of route objects rather than a wrapped response envelope.

Each item includes the route name, active state, and expanded input and output objects, so this method is a good fit for dashboards, listings, and route status views.

Request body parameters
Pagination
limit
integer

Maximum number of routes to return in one response page.

skip
integer

Offset used for pagination. Use 0 for the first page.

sort.created
integer

Sort direction for the route creation timestamp. The Swagger example uses 1 for ascending order.

Get all SRT routes
curl --request POST \
--url http://localhost/api/srt-routes/getAll \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"limit": 10,
"skip": 0,
"sort": {
"created": 1
}
}'
Response
Response list
[]
array

The live product returns a bare array of SRT route objects rather than a wrapped envelope.

router_name
string

Name of each SRT route in the returned array.

Source
input[]
array

Expanded input objects attached to the route, including the input type, input stream URL, and optional input_settings such as rcvbuf when configured.

Destination
output[]
array

Expanded output objects attached to the route, including the output type and output stream URL.

active
boolean

Whether the route is currently active.

success
boolean

Each returned item currently includes success: true in the live response.

Response: Get all SRT routes
JSON
[
{
"_id": "69c1de8e28c95839e0dffb74",
"router_name": "Awesome SRT route updated",
"input": [
{
"_id": "69c1de8e28c95839e0dffb91",
"input_type": "INPUT_TYPE_SRT_URL",
"input_stream_url": "srt://0.0.0.0:2034?mode=listener",
"module_name": "MODULE_SRT_ROUTERS",
"__v": 0
}
],
"output": [
{
"_id": "69c1de8e28c95839e0dffb94",
"output_type": "OUTPUT_TYPE_SRT_URL",
"output_stream_url": "srt://0.0.0.0:2035",
"module_name": "MODULE_SRT_ROUTERS",
"__v": 0
}
],
"active": false,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"__v": 0,
"modified": "2026-03-24T00:45:02.886Z",
"id": "69c1de8e28c95839e0dffb74",
"success": true
}
]
Get SRT route by id
Expand
POST
/api/srt-routes/getById

Loads one SRT route by id.

The current Swagger definition exposes this method as POST /api/srt-routes/getById with a simple body containing the route id.

In live product tests, this method returns the full route object on the top level together with expanded input and output arrays. That makes it the best method to call when you need the current persisted route configuration before rendering an edit form or a detailed route view.

Request body parameters
id
string

Identifier of the SRT route you want to load.

Get SRT route by id
curl --request POST \
--url http://localhost/api/srt-routes/getById \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"id": "SRT_ROUTE_ID"
}'
Response
_id
string

Identifier of the requested route.

router_name
string

Name of the requested route.

input[]
array

Expanded input objects for the route source. When advanced SRT input settings are used, the live product also returns them under input_settings.

output[]
array

Expanded output objects for the route destination.

active
boolean

Whether the route is currently enabled.

success
boolean

The live product returns the requested route object together with success: true.

Response: Get SRT route by id
JSON
{
"_id": "69c1de8e28c95839e0dffb74",
"router_name": "Awesome SRT route updated",
"input": [
{
"_id": "69c1de8e28c95839e0dffb91",
"input_type": "INPUT_TYPE_SRT_URL",
"input_stream_url": "srt://0.0.0.0:2034?mode=listener",
"module_name": "MODULE_SRT_ROUTERS",
"__v": 0
}
],
"output": [
{
"_id": "69c1de8e28c95839e0dffb94",
"output_type": "OUTPUT_TYPE_SRT_URL",
"output_stream_url": "srt://0.0.0.0:2035",
"module_name": "MODULE_SRT_ROUTERS",
"__v": 0
}
],
"active": false,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"__v": 0,
"modified": "2026-03-24T00:45:02.886Z",
"id": "69c1de8e28c95839e0dffb74",
"success": true
}
Update SRT route
Expand
POST
/api/srt-routes/update

Updates an existing SRT route by id.

The current Swagger definition exposes this method as POST /api/srt-routes/update with the route id plus the updated route body.

In live product tests, the response returns the updated route object on the top level together with success: true, but, just like create, the top-level input and output arrays come back empty immediately after update. If you need the expanded linked objects, call getById after the update succeeds.

Request body parameters
id
string

Identifier of the route you want to update.

router_name
string

Updated route name.

input
object

Updated source configuration object for the route.

output
object

Updated destination configuration object for the route.

active
boolean

Updated enabled state for the route.

Update SRT route
curl --request POST \
--url http://localhost/api/srt-routes/update \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"id": "SRT_ROUTE_ID",
"router_name": "Awesome SRT route updated",
"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_URL",
"output_stream_url": "srt://destination.example.com: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
}'
Response
router_name
string

Updated route name returned by the live product.

modified
string

Modification timestamp set by the product.

input
array

Immediately after update, the live product currently returns empty top-level input and output arrays.

success
boolean

The live product returns the updated route object together with success: true.

Response: Update SRT route
JSON
{
"router_name": "Awesome SRT route updated",
"input": [],
"output": [],
"active": true,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"_id": "69c1de8e28c95839e0dffb74",
"__v": 0,
"id": "69c1de8e28c95839e0dffb74",
"success": true,
"modified": "2026-03-24T00:45:02.811Z"
}
Start SRT route
Expand
POST
/api/srt-routes/start

Starts an SRT route by id.

The current Swagger definition exposes this method as POST /api/srt-routes/start with the route id in the request body.

In live product tests, the response returns the updated route on the top level together with success: true. After the route starts, the input and output fields are returned as linked object ids rather than expanded objects, and the route becomes active: true.

vMix note: this is a good fit for a button, shortcut, or trigger when the route already exists and operators only need to bring the path online at the right moment.

Request body parameters
id
string

Identifier of the route you want to start.

Start SRT route
curl --request POST \
--url http://localhost/api/srt-routes/start \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"id": "SRT_ROUTE_ID"
}'
Response
input
array

After start, the live product returns input as an array of linked input object ids.

output
array

After start, the live product returns output as an array of linked output object ids.

active
boolean

Becomes true when the route is started successfully.

success
boolean

The live product returns the updated route object together with success: true.

Response: Start SRT route
JSON
{
"_id": "69c1de8e28c95839e0dffb74",
"router_name": "Awesome SRT route updated",
"input": [
"69c1de8e28c95839e0dffb91"
],
"output": [
"69c1de8e28c95839e0dffb94"
],
"active": true,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"__v": 0,
"modified": "2026-03-24T00:45:02.853Z",
"id": "69c1de8e28c95839e0dffb74",
"success": true
}
Stop SRT route
Expand
POST
/api/srt-routes/stop

Stops an SRT route by id.

The current Swagger definition exposes this method as POST /api/srt-routes/stop with the route id in the request body.

In live product tests, the response returns the updated route on the top level together with success: true. The route becomes active: false, and the linked input and output values are still returned as ids rather than expanded objects.

vMix note: this pairs naturally with Start SRT route in operator-facing controls when you want a clean way to take the route offline without deleting it.

Request body parameters
id
string

Identifier of the route you want to stop.

Stop SRT route
curl --request POST \
--url http://localhost/api/srt-routes/stop \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"id": "SRT_ROUTE_ID"
}'
Response
input
array

After stop, the live product still returns linked input object ids rather than expanded objects.

output
array

After stop, the live product still returns linked output object ids rather than expanded objects.

active
boolean

Becomes false when the route is stopped successfully.

success
boolean

The live product returns the updated route object together with success: true.

Response: Stop SRT route
JSON
{
"_id": "69c1de8e28c95839e0dffb74",
"router_name": "Awesome SRT route updated",
"input": [
"69c1de8e28c95839e0dffb91"
],
"output": [
"69c1de8e28c95839e0dffb94"
],
"active": false,
"user_id": "69360341db559495f643de6a",
"created": "2026-03-24T00:45:02.729Z",
"__v": 0,
"modified": "2026-03-24T00:45:02.886Z",
"id": "69c1de8e28c95839e0dffb74",
"success": true
}
Get SRT routes count
Expand
POST
/api/srt-routes/getCount

Returns the number of SRT routes currently available to the authenticated user.

The current Swagger definition exposes this method as POST /api/srt-routes/getCount without a request body example. In live product tests, the response is a small object with a single count field.

This method is most useful for summaries, widgets, or API health checks where you only need the route count and not the route objects themselves.

Request body parameters
This method has no parameters
Get SRT routes count
curl --request POST \
--url http://localhost/api/srt-routes/getCount \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{}'
Response
Operation result
count
integer

Total number of SRT routes currently visible to the authenticated user.

Response: Get SRT routes count
JSON
{
"count": 1
}
Remove SRT route
Expand
DELETE
/api/srt-routes/remove

Deletes an SRT route and stops any processes attached to it.

The current Swagger definition exposes this method as DELETE /api/srt-routes/remove with the route id in the request body.

In live product tests, the response is not the deleted route object. Instead, the API returns a storage-level acknowledgment object with acknowledged and deletedCount.

Query parameters
id
string

Identifier of the route you want to delete.

Remove SRT route
curl --request DELETE \
--url http://localhost/api/srt-routes/remove \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"id": "SRT_ROUTE_ID"
}'
Response
Operation result
acknowledged
boolean

Indicates that the delete operation was acknowledged by the storage layer.

deletedCount
integer

Number of deleted SRT routes. On a successful remove call, this is typically 1.

Response: Remove SRT route
JSON
{
"acknowledged": true,
"deletedCount": 1
}