SRT servers

Use SRT servers to give remote encoders or partner systems secure, low-latency contribution through managed SRT ingest endpoints. Control publisher and receiver access, monitor live transport health in the authenticated Callaba operator experience, and prepare primary and backup PULL routes for reconnect and fallback after a disconnect.

What it doesReceive a reliable SRT contribution feed

Choose this whenYou need managed SRT ingest with access rules, transport telemetry, and primary/backup failover.

Use another module whenUse SRT Routes for unchanged forwarding; use Restreams for transcoding, overlays, or another output protocol.

1SRT source2Monitor and recover3Route or record

POST /api/srt-servers/create

Filter endpoints9 endpoints

Before you start

All management methods require a valid x-access-token. Reserve reachable SRT ports, coordinate latency and passphrase settings with the sender, and define publisher and receiver access before sharing connection details.

What you can do

create and update configure ports, latency, bandwidth, receive buffer, passphrase, access, callbacks, and routing hosts.
getAll, getCount, and getById inspect servers.
start and stop control the listener.
switchTo validates and stores a preferred configured PULL route. Apply the saved preference with a controlled stop and start maintenance sequence.
remove deletes the server.

Example workflow

Create a listener with the required port, latency, passphrase, and access rules.
Add primary and backup routing hosts when failover is required.
Start the server and connect the publisher.
Watch live bitrate, estimated bandwidth, round-trip time, buffers, and loss counters in the Callaba operator experience.
Interrupt the primary source during a controlled acceptance test and confirm in the authenticated operator experience that the configured reconnect and routing-host loop reaches a prepared backup.

Common use cases

Receive encrypted contribution from a remote camera or venue encoder.
Operate configured primary and backup SRT PULL feeds with reconnect and fallback behavior after a disconnect.
Control publisher and receiver access for partners or guest connections.
Monitor contribution health and connection origin during a live event.

Limits and troubleshooting

The sender and listener must agree on mode, port, latency, stream identity, and passphrase. Failover is not universally hitless: detection and recovery time depend on the real source, destination, reconnect interval, buffer, latency, and network. switchTo saves a configured route preference but does not reload a running relay. Apply it with a controlled stop and start, then verify live SRT health in the authenticated Callaba operator experience.

Next steps

Verify the live feed, then connect the server to SRT routes, Restreams, Recordings, Multiview, or Web players.

REST solution recipe

Build an SRT server gateway for contribution

Create a secure SRT ingest boundary for a remote production feed, start it, and confirm the saved access and routing configuration before routing the signal downstream.

Create the SRT gatewaySet ports, latency, passphrase, publisher and receiver access, and routing.POST /api/srt-servers/create
Start contribution ingestStart the listener before sharing connection details with the source.POST /api/srt-servers/start
Review the saved gatewayConfirm ports, access records, routing hosts, and active state through the authenticated resource.POST /api/srt-servers/getById

A successful create response confirms configuration, not media health. Start the resource, then verify its runtime statistics before sending production traffic.

See the SRT Server product

REST solution recipe

Prepare and validate an SRT primary/backup route set

Configure approved primary and backup sources on one PULL server, review the saved route set, and validate reconnect behavior during a controlled source interruption.

Configure the source setCreate a PULL server with the primary and backup URLs in routing_hosts.POST /api/srt-servers/create
Review the saved route setConfirm the server uses PULL routing and contains every approved primary and backup host.POST /api/srt-servers/getById
Start the configured relayStart the server only after the route order and connection settings have been reviewed.POST /api/srt-servers/start
Close the acceptance window safelyAfter validating primary loss and backup recovery in the operator experience, stop the temporary acceptance runtime when required.POST /api/srt-servers/stop
Finalize the production route setApply any reviewed timeout or route-order corrections while the server is in a controlled maintenance state.POST /api/srt-servers/update

This is reconnect-based recovery between configured sources, not packet-level hitless path redundancy. Validate recovery with real media in the authenticated Callaba operator experience.

See the live video failover product Open the live operator demo

Maintenance-safe REST workflow

Apply a preferred SRT source on the next controlled start

Review the configured PULL routes, stop the relay in a planned window, store the preferred source, and start the server so Engine regenerates the runtime with that preference.

Register primary and backupCreate a PULL server whose routing_hosts contains every URL the policy is allowed to select.POST /api/srt-servers/create
Review the allowed route setConfirm PULL mode and the exact saved URLs before entering the maintenance window.POST /api/srt-servers/getById
Stop the running relayEnter a controlled maintenance state before changing the saved route preference.POST /api/srt-servers/stop
Store the preferred sourceSend the server id and one exact srt_url already present in routing_hosts.POST /api/srt-servers/switchTo
Regenerate and startStart the server so the relay configuration is regenerated with the saved route preference, then verify live media in the operator experience.POST /api/srt-servers/start

switchTo validates and saves the configured route preference; it does not reload a running relay. Treat stop, switchTo, and start as one planned maintenance transaction.

See the live video failover product Open the live operator demo

REST solution recipe

Control SRT publisher and receiver access

Choose an open guest boundary, an IP allowlist, or a passphrase-protected listener when you create the server, then inspect the populated access records before distributing connection details.

Create the access boundarySet stream_control_type and access_settings for the chosen policy together with ports, latency, and optional passphrase.POST /api/srt-servers/create
Verify saved access recordsRead the populated access relation and confirm publisher and receiver roles before sharing URLs.POST /api/srt-servers/getById
Rotate the policy safelySend the complete desired server and access state when moving between guest, allowlist, or protected operation.POST /api/srt-servers/update

CONTROL_ACCESS_ALLOW_ALL accepts arbitrary publisher or receiver identities and should be limited to intentional guest workflows. Use CONTROL_ACCESS_IP_ADDRESS plus access_settings for known hosts; add an SRT passphrase when transport encryption is required.

See the SRT Server product Open the live operator demo

POST

/api/srt-servers/create

API token required

Create an SRT listener with its ports, latency, buffering, encryption, routing, monitoring, and access-control settings. Send the dashboard-issued JWT in the x-access-token header.

Choose routing_type for a standalone, push, or pull listener. Do not send a separate server_fc field; Callaba calculates flow control from server_rcvbuf.

Units are significant: server_latency is milliseconds, server_timeout is seconds, server_maxbw is bytes per second, and server_rcvbuf is bytes.

Request examples

Choose a preset for no routing, public-IP routing, Callaba routing, or security and monitoring. A vMix Script example is available for operator-driven provisioning.

Common use cases

Provide OBS, a field encoder, or a partner feed with a stable contribution endpoint.
Configure push or pull routing for a backup source or a managed handoff.
Apply a passphrase, access rules, and event/statistics callbacks to an ingest boundary that operations must monitor.

No routing

These examples keep routing disabled and rely on the server itself as the stable ingest boundary.

Standalone SRT server

Use this shape when the server should act as a plain local SRT ingest endpoint without any routing layer. It is the simplest contract and the closest to the basic dashboard form.

Standalone SRT server

PUBLIC_IP routing

The PUBLIC_IP mode is for direct routing to public network addresses. Use PUSH when this server should actively send toward the remote endpoint. Use PULL when the remote side should be treated as the upstream that this server reaches out to.

PUBLIC_IP routing with PUSH

Use this shape when the server should actively push toward a public-IP routing target. Each routing host needs a host and port, while routing_server_name stays optional in this mode.

PUBLIC_IP routing with PUSH

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "PUBLIC_IP",
  "routing_type": "PUSH",
  "routing_hosts": [
    {
      "routing_host": "203.0.113.50",
      "routing_port": 1935
    }
  ]
}'

PUBLIC_IP routing with PULL

Use this shape when the routed side should be pulled instead of pushed. In practice this is the public-IP sibling of the push example, but with a pull lifecycle.

PUBLIC_IP routing with PULL

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "PUBLIC_IP",
  "routing_type": "PULL",
  "routing_hosts": [
    {
      "routing_host": "198.51.100.22",
      "routing_port": 1935,
      "routing_server_name": "primary-edge-srt"
    },
    {
      "routing_host": "203.0.113.50",
      "routing_port": 1935,
      "routing_server_name": "backup-edge-srt"
    }
  ]
}'

CALLABA routing

The CALLABA routing mode uses named routing hosts and is the stricter variant: host, port, and server name are all required. Use PUSH when this server should send into the Callaba-side route, and PULL when the Callaba-side route should behave as the upstream relationship you attach to.

CALLABA routing with PUSH

Use this shape when the server should route toward the Callaba cloud path in push mode. In this routing mode each host item must also carry routing_server_name.

CALLABA routing with PUSH

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "CALLABA",
  "routing_type": "PUSH",
  "routing_hosts": [
    {
      "routing_host": "ingest.callaba.cloud",
      "routing_port": 1935,
      "routing_server_name": "callaba-route-primary"
    }
  ]
}'

CALLABA routing with PULL

Use this shape when the routed Callaba side should be pulled instead of pushed. It keeps the same named routing host contract while switching the routing type.

CALLABA routing with PULL

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "CALLABA",
  "routing_type": "PULL",
  "routing_hosts": [
    {
      "routing_host": "ingest.callaba.cloud",
      "routing_port": 1935,
      "routing_server_name": "callaba-route-backup"
    }
  ]
}'

Security and monitoring

These examples keep the basic ingest shape but turn on one advanced capability at a time so it is easier to copy the exact fields you need.

Passphrase-protected SRT server

Use this shape when the ingest endpoint should require SRT encryption. The example uses a 16-character passphrase, which matches the product guidance for AES-128 sized protection.

Best fit: shared ingest points, partner contribution, or any case where the listener should not accept cleartext SRT sessions by default.

Passphrase-protected SRT server

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "DISABLED",
  "routing_hosts": [],
  "passphrase": "0123456789abcdef"
}'

SRT server with statistics callback

Use this shape when the server should post SRT statistics to an external monitoring endpoint. The backend validates the callback URL and interval together.

Best fit: managed events, support workflows, and long-running ingest points where you want external telemetry without polling the full server object.

SRT server with statistics callback

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "DISABLED",
  "routing_hosts": [],
  "stats_host": "https://monitoring.example.com/api/srt-stats",
  "stats_interval": 2
}'

SRT server with IP-based access control

Use this shape when only specific publisher or receiver hosts should be allowed. Each entry requires host and role_name when stream_control_type is CONTROL_ACCESS_IP_ADDRESS.

Best fit: controlled ingest from known sites or fixed peer addresses. If peers change often, this mode is stricter to operate than a simple open listener.

SRT server with IP-based access control

curl --request POST \
  --url http://localhost/api/srt-servers/create \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "server_name": "Awesome SRT server",
  "server_type": "SERVER_TYPE_SRT",
  "server_port": 1935,
  "server_receiver_port": 1936,
  "server_latency": 200,
  "server_maxbw": -1,
  "server_timeout": 60,
  "server_rcvbuf": 48234496,
  "server_active": true,
  "routing": "DISABLED",
  "routing_hosts": [],
  "stream_control_type": "CONTROL_ACCESS_IP_ADDRESS",
  "access_settings": [
    {
      "host": "203.0.113.44",
      "role_name": "publisher"
    },
    {
      "host": "203.0.113.45",
      "role_name": "receiver"
    }
  ]
}'

Request body parameters

Basic settings

server_name

string

Dashboard label: Name.

Set such a name for the created item to avoid confusion in the future. The validation layer accepts from 1 to 60 characters.

server_type

string

Current validated API contract accepts SERVER_TYPE_SRT.

The model still defines SERVER_TYPE_WEBRTC, but the live create/update validation currently allows only the SRT server type.

server_active

boolean

Dashboard label: Enable once created.

Enabled is a server state. Disconnecting the server turns off connections and data transfers for all publishers and recipients connected to this SRT server.

Ports and latency

server_port

integer

Dashboard label: Port.

Port used for listening to the SRT server. The live validation accepts values from 1024 to 65535.

server_receiver_port

integer

Dashboard label: Receiver port.

Port used for receiving SRT streams. The current validated API also expects a value from 1024 to 65535.

The runtime has a fallback path when this port is missing, but the public create/update contract still requires it explicitly.

server_latency

integer

Dashboard label: Latency.

Latency is configured in milliseconds. The product guidance recommends using roughly ping × 4, with an absolute practical floor of about 120 ms for stable SRT contribution.

For practical setup guidance, see Find the perfect latency for your SRT setup.

server_maxbw

integer

Dashboard label: Max network bandwidth.

Network bandwidth or bitrate in Byte/s. Use -1 for unlimited. The validation layer currently accepts values up to 3125000000.

server_timeout

integer

Dashboard label: Stream inactivity timeout.

Configured in seconds. When the timeout is reached, the server disconnects the client. -1 means unlimited timeout.

server_rcvbuf

integer

Dashboard label: Receiver buffer size.

This field is expressed in bytes. The REST API accepts 12058624 to 200000000.

The dashboard starts at 12058624 and recommends 48234496 for production. Flow control is derived from this receive buffer, so you do not send a separate server_fc field.

Security and identity

passphrase

string

Dashboard label: Passphrase.

Optional SRT encryption secret for the ingest endpoint. The dashboard guidance recommends a length of 16, 24, or 32 characters for AES-128, AES-192, and AES-256 sized passphrases.

Routing and backup

routing

string

Dashboard section: Routing settings.

Controls whether the SRT server runs as a local standalone ingress or as a routed endpoint. The validated values are DISABLED, PUBLIC_IP, and CALLABA.

This choice affects which runtime config template is selected: standalone, push, or pull routing mode.

routing_type

string

Routing strategy used when routing is enabled. The server model defines PUSH and PULL.

routing_hosts

array

List of routing targets.

For CALLABA routing, each item must contain routing_host, routing_port, and routing_server_name. For PUBLIC_IP, the host and port are required while the server name stays optional.

The product also links this mode to backup-stream workflows. See how to set up an SRT backup stream in case of a main stream interruption.

Statistics callbacks

stats_host

string

Optional callback URL for SRT statistics delivery. When set, the value must be a valid http or https URI.

stats_interval

integer

Statistics posting interval in seconds.

Create/update validation accepts values from 1 to 10. If statistics are enabled and no interval is provided, the service falls back to 1 second.

Access control

stream_control_type

string

Control mode for per-stream access validation. When the value is set to IP-address based access control, the backend validates the related access_settings entries as host and role objects.

access_settings

array

Optional list of access rules or stream identities created together with the server.

In responses, these appear as related access records rather than as the original request payload.

Create SRT server

Response

Identity and ports

_id

string

Resource id returned when you create or list the SRT server.

string

Convenience alias for the server identifier. In the live response, id matches _id.

server_name

string

Name stored for the created SRT server.

server_name_code

string

Slug-style code generated from server_name. The backend derives it with friendly URL normalization.

server_type

string

Type of the created server, for example SERVER_TYPE_SRT.

server_port

string

Listening port returned by the product for the created SRT server.

server_receiver_port

string

Receiver port returned by the product for the created SRT server.

server_port_id

string

Assigned UDP port document for the publisher side of the server.

server_receiver_port_id

string

Assigned UDP port document for the receiver side of the server.

Runtime profile

server_latency

integer

Configured latency value in milliseconds.

server_maxbw

integer

Configured maximum bandwidth in Byte/s.

server_timeout

string

Configured inactivity timeout in seconds. The live document currently serializes it as a string.

server_rcvbuf

integer

Receive buffer size in bytes. Flow control is derived from this value.

server_active

boolean

Whether the created server is enabled immediately after creation.

Security, routing, and monitoring

passphrase

string

Stored encryption field for the server. If passphrase protection is enabled, the backend stores an encoded value rather than a plaintext secret.

server_publisher

string

Publisher-side stream-id or URL prefix stored with the server.

server_player

string

Receiver-side stream-id or URL prefix stored with the server.

routing_hosts

array

Routing targets saved with the server. In the minimal default create flow this is an empty array.

stats_interval

integer

Resolved statistics interval. The live create flow defaults to 1.

Access and metadata

access

array

Related access stream records for this SRT server. getById populates these more deeply than create/update.

server_user_id

string

Owner user identifier attached by the backend.

server_created

string

Creation timestamp returned by the live product.

server_modified

string

Last modification timestamp returned by the live product.

__v

integer

Document version field returned by the model serialization.

success

boolean

The live product returns a boolean success flag together with the created SRT server object. On successful creation it is true.

Response: Create SRT server

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-23T23:54:23.983Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

POST

/api/srt-servers/getCount

API token required

POST

/api/srt-servers/getAll

API token required

Returns a list of SRT servers from Callaba Engine.

Send optional pagination and sorting fields in the request body. The response is a bare array of SRT server objects.

Authentication uses the dashboard-issued JWT token in the x-access-token header.

Request body parameters

Pagination

limit

integer

Maximum number of SRT servers to return in one response page.

skip

integer

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

sort

object

Optional sort object. If omitted, the service defaults to { server_created: 1 }.

Filtering

filter

object

Optional filter object merged into the server query for the current user.

Get all SRT servers

Response

Response list

[]

array

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

_id

string

Identifier of each SRT server returned in the array.

server_name

string

Name of the SRT server.

server_type

string

Type of the SRT server, for example SERVER_TYPE_SRT.

server_port

string

Listening port of the SRT server.

server_receiver_port

string

Receiver port of the SRT server.

server_active

boolean

Whether the server is currently enabled.

stats_interval

integer

Resolved statistics interval for each server object when present.

success

boolean

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

Response: Get all SRT servers

JSON

[
  {
    "_id": "69c1d2af28c95839e0dfea90",
    "__v": 0,
    "access": [],
    "id": "69c1d2af28c95839e0dfea90",
    "passphrase": "",
    "routing_hosts": [],
    "server_active": true,
    "server_created": "2026-03-23T23:54:23.979Z",
    "server_latency": 200,
    "server_maxbw": -1,
    "server_modified": "2026-03-23T23:54:23.983Z",
    "server_name": "Awesome SRT server",
    "server_name_code": "awesome-srt-server",
    "server_player": "receiver",
    "server_port": "1935",
    "server_port_id": "69c1d2af28c95839e0dfeaa0",
    "server_publisher": "publisher",
    "server_rcvbuf": 48234496,
    "server_receiver_port": "1936",
    "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
    "server_timeout": "60",
    "server_type": "SERVER_TYPE_SRT",
    "server_user_id": "69360341db559495f643de6a",
    "stats_interval": 1,
    "success": true
  }
]

POST

/api/srt-servers/getById

API token required

Loads one SRT server by its identifier.

Send the server id in the request body. The response contains the full SRT server object and success: true.

Authentication uses the dashboard-issued JWT token in the x-access-token header.

Request body parameters

Lookup

string

Identifier of the SRT server you want to load.

Get SRT server by id

Response

Core server object

_id

string

Identifier of the requested SRT server.

server_name

string

Name of the requested SRT server.

server_type

string

Type of the SRT server.

server_port

string

Listening port of the SRT server.

server_receiver_port

string

Receiver port of the SRT server.

Operational settings

passphrase

string

Stored passphrase field for the server.

server_publisher

string

Publisher prefix stored for the server.

server_player

string

Receiver prefix stored for the server.

routing_hosts

array

Routing hosts stored with the server, when routing is configured.

stats_interval

integer

Configured statistics interval.

Access and status

access

array

The service populates related access stream records on getById, so this endpoint is the best place to inspect the full access layer attached to a server.

server_active

boolean

Whether the server is currently enabled.

success

boolean

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

Response: Get SRT server by id

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-23T23:54:23.983Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

POST

/api/srt-servers/start

API token required

Starts an existing SRT server by id.

A successful call marks the server active and starts listening with its saved configuration. Use it to bring a provisioned ingest point online without recreating it.

Request body parameters

Operation input

string

Identifier of the SRT server to start.

Start SRT server

Response

Operation result

server_active

boolean

After a successful start request the live product returns the server object with server_active: true.

server_modified

string

Updated modification timestamp written during the start operation.

success

boolean

The returned document still includes success: true.

Response: Start SRT server

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-23T23:54:23.983Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

POST

/api/srt-servers/stop

API token required

Stops an existing SRT server by id.

A successful call marks the server inactive, stops its listener, and clears recent runtime statistics and event-log state for that port. The saved server remains available for a later start.

Request body parameters

Operation input

string

Identifier of the SRT server to stop.

Stop SRT server

Response

Operation result

server_active

boolean

After a successful stop request the live product returns the server object with server_active: false.

server_modified

string

Updated modification timestamp written during the stop operation.

success

boolean

The returned document still includes success: true.

Response: Stop SRT server

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": false,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-23T23:54:23.983Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

POST

/api/srt-servers/switchTo

API token required

Store a preferred upstream for an SRT server configured with routing_type: PULL. The requested srt_url must exactly match a URL in the saved routing hosts.

This call updates configuration only; it does not reload a running relay. To apply the preference, stop the server in a planned maintenance window, call switchTo, start the server, and verify live media in the authenticated Callaba operator experience.

Common use cases

Choose the preferred backup before a controlled server start.
Restore the primary preference before service resumes after maintenance.
Prepare a reviewed route order before a live-event acceptance window.

Request body parameters

Target server

string

Identifier of an SRT server owned by the authenticated user.

Approved upstream

srt_url

string

Exact SRT URL already present in the server's configured routing_hosts. The server must use routing_type: PULL.

Store the preferred SRT pull route

Response

Saved route preference

active_route

string

The saved preferred upstream URL. This value is configuration state only; it does not prove that a running relay changed source.

Route state

routing_type

string

The endpoint accepts only a server configured for PULL.

Operation result

server_modified

string

Timestamp written when the route preference is saved. Use a controlled stop and start sequence to regenerate the relay with this preference.

Response: Store the preferred SRT pull route

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-06-25T10:12:00.000Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true,
  "routing": "PUBLIC_IP",
  "routing_type": "PULL",
  "active_route": "srt://203.0.113.50:1935?streamid=receiver/backup-edge-srt"
}

POST

/api/srt-servers/update

API token required

Updates an existing SRT server resource in Callaba Engine.

The update contract mirrors the create contract closely: you can adjust ports, latency, buffering, passphrase protection, routing, statistics callbacks, and access-control settings in the same request shape, while targeting an existing server id.

If you pass ********** as the passphrase placeholder, Callaba preserves the existing passphrase instead of replacing it.

Authentication uses the dashboard-issued JWT token in the x-access-token header.

Request body parameters

Target

string

Identifier of the SRT server you want to update.

Basic settings

server_name

string

Updated display name for the SRT server.

server_type

string

Updated server type. The current validated API still expects SERVER_TYPE_SRT.

server_active

boolean

Updated enabled state for the server.

Ports and latency

server_port

integer

Updated listening port.

server_receiver_port

integer

Updated receiver port.

server_latency

integer

Updated latency value in milliseconds.

server_maxbw

integer

Updated maximum bandwidth in Byte/s.

server_timeout

integer

Updated inactivity timeout in seconds.

server_rcvbuf

integer

Updated receiver buffer size. The live product accepts the same recommended values used during create.

Security and identity

passphrase

string

Updated passphrase. Sending ********** preserves the existing encrypted value in the backend service.

Routing and backup

routing

string

Updated routing mode.

routing_type

string

Updated routing type, such as PUSH or PULL.

routing_hosts

array

Updated routing target list.

Statistics callbacks

stats_host

string

Updated callback URL for SRT statistics.

stats_interval

integer

Updated statistics interval in seconds.

Access control

stream_control_type

string

Updated access-control mode for streams attached to the server.

access_settings

array

Updated access rules or stream identities to recreate alongside the server.

Update SRT server

Response

Operation result

_id

string

Identifier of the updated SRT server.

server_name

string

Updated name returned by the product.

server_modified

string

Modification timestamp updated by the product.

success

boolean

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

Response: Update SRT server

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-24T00:35:53.847Z",
  "server_name": "Awesome SRT server updated",
  "server_name_code": "awesome-srt-server-updated",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

DELETE

/api/srt-servers/remove

API token required

Deletes an SRT server and stops its listener.

Send the server id in the request body. The response contains the deleted SRT server object and success: true.

Authentication uses the dashboard-issued JWT token in the x-access-token header.

Query parameters

Operation input

string

Identifier of the SRT server to delete.

Remove SRT server

Response

Operation result

_id

string

Identifier of the deleted SRT server.

server_name

string

Name of the deleted SRT server.

success

boolean

The live product returns the deleted server object together with success: true.

Response: Remove SRT server

JSON

{
  "_id": "69c1d2af28c95839e0dfea90",
  "__v": 0,
  "access": [],
  "id": "69c1d2af28c95839e0dfea90",
  "passphrase": "",
  "routing_hosts": [],
  "server_active": true,
  "server_created": "2026-03-23T23:54:23.979Z",
  "server_latency": 200,
  "server_maxbw": -1,
  "server_modified": "2026-03-23T23:54:23.983Z",
  "server_name": "Awesome SRT server",
  "server_name_code": "awesome-srt-server",
  "server_player": "receiver",
  "server_port": "1935",
  "server_port_id": "69c1d2af28c95839e0dfeaa0",
  "server_publisher": "publisher",
  "server_rcvbuf": 48234496,
  "server_receiver_port": "1936",
  "server_receiver_port_id": "69c1d2af28c95839e0dfeaa1",
  "server_timeout": "60",
  "server_type": "SERVER_TYPE_SRT",
  "server_user_id": "69360341db559495f643de6a",
  "stats_interval": 1,
  "success": true
}

Back toInstallation or instant launch Next toAuthorization

Move live video

Monitor and protect

Publish and monetize

Build and interact

Live operations

Deployment

Playback and delivery

Monetization

Industries

Ingest and route

Store, publish and interact

Learn and operate

About Callaba

SRT servers

Before you start

What you can do

Example workflow

Common use cases

Limits and troubleshooting

Next steps

Build an SRT server gateway for contribution

Prepare and validate an SRT primary/backup route set

Apply a preferred SRT source on the next controlled start

Control SRT publisher and receiver access

Request examples

Common use cases

Common use cases