Callaba is one streaming engine with two operating surfaces: a dashboard for operators and an API for engineers.
Run live workflows in the product, automate the same module boundaries over API, and keep one operating model across cloud and self-hosted deployments.
The dashboard is where broadcast teams run the workflow. The API is where product, platform, and tooling teams automate the same boundaries inside internal tools, portals, schedulers, and reliability layers.
Broadcast teams can monitor ingest, routes, recordings, players, calls, and storage from one operational surface instead of jumping between separate tools.
Engineering teams do not need a second product model. The same SRT, restream, recording, playback, and storage layers are available as clean API modules.
Both surfaces sit on top of the same live runtime, which is why the next section starts with the transport signals operators and developers end up trusting together.
The platform works best when you treat it as cooperating workflow modules instead of one big video black box. That same shape now runs through the product, the API docs, and the packaged surfaces below.
Create stable SRT or RTMP ingress points before the workflow branches into routing, restreaming, recording, or playback.
Route to partner endpoints, social outputs, backup paths, players, and internal handoff layers without rebuilding around each destination.
Turn the same live or file-based source into web players, paywalled pages, grouped playback surfaces, and browser-based rooms.
Use the API, live stats, recordings, files, and storage layers as one control plane instead of a pile of separate tools.
Once that model is clear, the examples below show how the same layers appear in the product UI and over API.
Start with cloud if you need a fast proof of value, go straight to the API if the workflow is already clear, or choose self-hosted when ownership of infrastructure and data is the first requirement.
