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 transport health, and switch between primary and backup sources.

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 endpoints12 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.
getActiveStreams reports current stream identities and available connection details.
getEventLogBySRTPort returns connection events for a server port.
getStatisticHistory returns the available recent transport history for a server port.
switchTo selects a configured route for supported PULL failover workflows.
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 bitrate, estimated bandwidth, round-trip time, active streams, and connection events.
Allow automatic failover, or use switchTo for a manual change to an exact configured URL on a supported PULL server.

Common use cases

Receive encrypted contribution from a remote camera or venue encoder.
Operate primary and backup SRT feeds with automatic and manual switching.
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. switchTo applies only to a supported PULL server and an exact SRT URL already configured in its routing hosts. Live statistics are operational signals; export them when longer retention is required.

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 source state and recent transport history 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
Check transport historyReview the available per-stream samples for the selected SRT port.GET /api/srt-servers/:serverPort/getStatisticHistory

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

Switch a primary/backup SRT contribution source by REST API

Configure approved contribution sources on one PULL server, monitor source state and transport history, then switch the active route manually or from your own control policy.

Configure the source setCreate a PULL server with the primary and backup URLs in routing_hosts.POST /api/srt-servers/create
Check current activityRead the active stream identities before making a routing decision.POST /api/srt-servers/getActiveStreams
Inspect connection eventsUse connect and close events for the selected listen port as one health signal.POST /api/srt-servers/getEventLogBySRTPort
Review recent transport historyCompare the available per-stream history with your own failover thresholds.GET /api/srt-servers/:serverPort/getStatisticHistory
Switch to the approved backupSend the server id and the exact configured backup srt_url, then repeat the activity and event checks.POST /api/srt-servers/switchTo

This is route failover between configured sources, not packet-level hitless path redundancy. The server must use PULL routing and the exact SRT URL must already exist in routing_hosts.

See the live video failover product

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

Manually select an 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 changes the selected upstream; it does not provide automatic failover. Verify active streams, the event log, and statistics history after switching.

Common use cases

Move contribution to a reviewed backup encoder during an incident.
Return to the primary upstream after maintenance.
Exercise a planned failover path before a live event.

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.

Switch the active SRT pull route

Response

Route state

active_route

string

The selected upstream URL after a successful manual override.

routing_type

string

The endpoint accepts only a server configured for PULL.

Operation result

server_modified

string

Timestamp written when the active route changes.

Response: Switch the active 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/getActiveStreams

API token required

POST

/api/srt-servers/getEventLogBySRTPort

API token required

Returns the recent event log for a specific SRT server port.

This is the endpoint to use when you need connection history for a single port, including recent on_connect and on_close entries, peer information, and stream identifiers.

Request body parameters

Lookup

srt_port

string

SRT listen port whose event log you want to inspect.

Pagination

limit

integer

Maximum number of most recent log entries to return.

offset

integer

Optional offset counted from the end of the log buffer when you want older slices.

Get event log by SRT port

Response

Response list

[]

array

Array of recent event-log entries for the selected SRT port. The live API returns an empty array when nothing has happened yet.

Event entry

event_name

string

Name of the event, such as on_connect or on_close.

module_name

string

Origin module for the event, typically MODULE_SRT_SERVERS.

host

string

Remote host associated with the event.

port

string

SRT server port that produced the event.

udp_port

string

Peer UDP port captured for the event.

stream_id

string

Publisher or receiver stream identifier when available.

role_name

string

Role attached to the event, such as publisher or receiver.

active

boolean

Whether the event was recorded while the stream entry was active.

event_created

string

Timestamp attached to the event-log record.

Response: Get event log by SRT port

JSON

GET

/api/srt-servers/:serverPort/getStatisticHistory

API token required

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