RTMP servers
Use RTMP servers to receive OBS, encoder, and guest publishers at stable RTMP ingest endpoints. Control publishing and playback access, then inspect live bitrate and connection data.
Choose this whenOBS, an RTMP encoder, or a guest needs a stable push URL, access control, and live connection analytics.
Use another module whenUse SRT Servers for SRT transport and failover; use Streams only for identities inside an existing server.
/api/rtmp-servers/createBefore you start
All management methods require a valid x-access-token. Reserve a reachable listen port and choose the server's stream-control and access settings before sharing connection details.
What you can do
createandupdateconfigure the listen port, player buffer, and stream access policy.getAll,getCount, andgetByIdinspect servers and allowed stream records.startandstopcontrol the RTMP listener.getStatisticsreports input and output bitrate, publisher and receiver counts, plus available client address, region, and application metadata.getStatisticHistoryreturns the available recent statistics history.removedeletes the server.
Example workflow
- Create the RTMP server with its listen port and player buffer.
- Choose stream-key or IP-based access, or allow guest connections only when the workflow calls for it.
- Start the listener and give each publisher the intended connection details.
- Call
getStatisticsto verify bitrate, roles, and connection origin. - Connect the ingest to a recording, restream, or web player.
Common use cases
- Receive recurring OBS or encoder contributions at one stable endpoint.
- Let approved guest publishers and receivers create their own stream keys under the selected access policy.
- Monitor customer or venue connections by bitrate, role, address, and region.
- Turn an RTMP contribution feed into HLS or DASH browser playback.
Limits and troubleshooting
The port must be free and reachable. Access rules, stream keys, and publisher or receiver roles must match the connection. Recent statistics are operational data rather than a durable analytics store; export them when longer retention or alerting is required.
Next steps
Validate a publisher with getStatistics, then connect the server to Restreams, Recordings, or Web players.
Accept RTMP publishers and inspect live bitrate
Provision an RTMP entry point with the required access policy, start it, and read current and recent process statistics from the same server resource.
- Create RTMP ingestChoose the listen port, buffer, and open, stream-id, or IP access pattern.
POST /api/rtmp-servers/create - Start the serverEnable the entry point before connecting OBS, an encoder, or another publisher.
POST /api/rtmp-servers/start - Read live statisticsInspect current bitrate and connection data, then use history for recent samples.
POST /api/rtmp-servers/getStatistics
A successful create response confirms configuration, not media health. Start the resource, then verify its runtime statistics before sending production traffic.
See the RTMP Server productCreate an RTMP ingest server with its listen port, player buffer, active state, and optional stream-key or IP access rules. Send the dashboard-issued JWT in the x-access-token header.
server_buflen is measured in seconds. The default is 5, and accepted values are 1 through 120.
When stream_control_type and access_settings are supplied, Callaba creates the access rules with the server. The create response can still contain access: []; call getById to read the populated access list.
Request examples
Choose a preset for open ingest, explicit stream keys, or fixed IP addresses. A vMix Script example is available for operator-driven provisioning.
Common use cases
- Give OBS or another software encoder a stable RTMP contribution endpoint.
- Restrict partner or studio publishing with stream keys or an IP allowlist.
- Provision an ingest boundary that can feed browser playback through its associated HLS or DASH delivery.
Use this pattern when publishers and receivers should authenticate with explicit RTMP stream keys instead of open ingest. It mirrors the dashboard preset that seeds one publisher key and one receiver key.
Use this pattern when the RTMP peers are known fixed hosts. The dashboard preset creates publisher and receiver rules keyed by host instead of stream id.
Dashboard label: Name.
The form defaults to Live. Validation requires a non-empty value and rejects slashes.
Current validated API contract accepts SERVER_TYPE_RTMP.
Dashboard label: Enable once created.
Enabled is the server state. Turning it off disconnects all publishers and receivers attached to the RTMP server.
Dashboard label: Port.
The dashboard starts at 1945. The REST API accepts ports from 1 to 65535. Choose a free port that is reachable by your publishers and viewers.
Dashboard label: Buffer length (s).
This value is configured in seconds. The dashboard starts at 5 and the accepted range is 1 to 120.
This setting controls how much media the player buffers before playback starts.
Dashboard section: Allowed streams.
Controls whether the RTMP server validates incoming publishers and receivers by explicit stream key or by host allowlist. The live create flow currently uses values such as CONTROL_ACCESS_STREAM_ID and CONTROL_ACCESS_IP_ADDRESS.
Optional set of access rules to create together with the server.
For stream-key mode, each item typically contains stream_id and role_name. For IP-based mode, each item uses host and role_name.
Resource id returned when you create or list the RTMP server.
Convenience alias for _id.
Name stored for the RTMP server.
Type of the server. The live product returns SERVER_TYPE_RTMP.
Listening RTMP port returned by the product.
Configured RTMP buffer length.
Current running state flag stored on the server object.
Port document attached to the RTMP listener.
Creation timestamp.
Last modification timestamp.
Access-control mode stored on the RTMP server, when provided.
The live create response currently returns this as an empty array even when access_settings were submitted. Use getById to retrieve the populated related access records.
The model exposes success: true as a virtual field in successful responses.