Callaba Engine documentation
Use Callaba Engine API to automate live-video workflows end to end: receive SRT or RTMP feeds, route or transcode them, record them, and publish browser playback. Choose the section that matches the task you want to automate.
Choose this whenYou know the video outcome but not which Callaba resource to create.
Use another module whenOpen a module directly when you already know the resource that owns the job.
Choose a module by outcome
| Goal | Start with | Add next | Choose something else when |
|---|---|---|---|
| Receive OBS or another RTMP publisher | RTMP Servers | Recording, Restream, or Web Player | The source sends SRT instead of RTMP |
| Receive resilient SRT contribution | SRT Servers | Multiview, Recording, or Restream | You only need unchanged SRT forwarding |
| Send a live source to platforms or another protocol | Restreams | Web Player or Recording | The handoff stays SRT and needs no processing |
| Monitor several live feeds together | Multiview | SRT failover or Recording | The page is intended for an audience, not operators |
| Turn a live source into a file | Recordings | Files and Storages | The media already exists as a file |
| Publish browser playback | Web Players | Web Player Groups | Operators need a multiviewer instead |
| Bring remote guests into production | Video Calls | NDI Adapter or Recording | The contributor sends from an encoder |
Before you start
- Deploy or launch a Callaba Engine instance and note its base URL.
- Create an API token in General settings.
- Send the token in the
x-access-tokenheader over HTTPS. - Keep the token in a backend or another trusted environment.
What you can do
- Ingest: accept contribution with SRT servers, RTMP servers, streams, or video calls.
- Route and process: use SRT routes, restreams, NDI adapters, and recordings.
- Store and deliver: manage files and storages, then publish with web players or player groups.
- Operate: start, stop, update, remove, and inspect runtime statistics where the module supports them.
Example workflow
- Create an SRT or RTMP server for the contribution feed.
- Create a recording or restream that uses the server as its input.
- Create a web player when the output must be viewed in a browser.
- Start the resources in dependency order and check their runtime status.
- Stop downstream jobs before removing the ingest resource.
Common use cases
- Provision repeatable contribution, recording, and playback for recurring events.
- Connect a booking, control-room, or customer portal to live-video operations.
- Operate several Callaba instances with the same deployment and monitoring logic.
Limits and troubleshooting
Validate identifiers, enum values, ports, and required nested objects before sending a request. A saved resource is not proof that its media process is healthy, so check runtime statistics after starting it. Respect dependencies: an input cannot work after its upstream resource is stopped or removed.
Next steps
Read Installation or instant launch, then Authorization. After that, open the module that matches the first stage of your workflow.
Compose ingest, monitoring, recording, and delivery
Build one production control plane in dependency order: receive the contribution feed, expose it to operators, capture it, and create independently observable outputs for each destination.
- Create contribution ingestDefine the listener, latency, access policy, and any approved primary/backup routing hosts.
POST /api/srt-servers/create - Start and verify the sourceMake the upstream boundary healthy before any dependent resource is started.
POST /api/srt-servers/start - Create operator monitoringAdd the reviewed source to an authenticated operator layout.
POST /api/multiview/create - Start the operator wallVerify the contribution feed visually before opening capture and delivery branches.
POST /api/multiview/start - Create the archive branchBind the documented SRT input preset to the required recording format and retention policy.
POST /api/recording/create - Start captureStart the archive branch after operator monitoring confirms usable media.
POST /api/recording/start - Create each delivery branchCreate one job per destination with only the remuxing or transcoding that target requires.
POST /api/restream/create - Start downstream deliveryStart outputs independently so one destination cannot block the others.
POST /api/restream/start - Observe each outputCompare process state, bitrate, and frame cadence per branch during the event.
POST /api/restream/getStat
Module ids are not interchangeable. Use the exact input preset and source_id documented by each downstream create method, start upstream dependencies first, and roll back only the failed branch instead of restarting the whole workflow.
Receive SRT, record it, and publish browser playback
Use one Callaba API surface to compose ingest, route control, recording, and browser playback. Build in dependency order, then extend the same workflow with storage, multiview, or restream delivery in cloud or self-hosted deployments.
- Create SRT ingestConfigure the listener, latency, access rules, and source routing.
POST /api/srt-servers/create - Start and verify ingestStart the server before creating jobs that depend on its live input.
POST /api/srt-servers/start - Create the archive jobChoose the SRT server input preset and the required continuous or segmented output.
POST /api/recording/create - Start recordingStart capture only after the contribution input is healthy.
POST /api/recording/start - Create browser deliveryUse the SRT server input preset, then configure HLS or DASH and viewer access.
POST /api/vod/create - Start and test playbackStart the player, verify its runtime status, and test the viewer URL.
POST /api/vod/start
Each create response supplies the resource id needed by its start call. Use the input preset documented by the downstream module; do not substitute an id from another resource type.
Take a church service from ingest to multistream, recording, and playback
Build one repeatable service workflow in dependency order: accept the programme feed, start each destination, retain the service, and publish browser playback.
- Create service ingestConfigure the RTMP entry point used by the church encoder.
POST /api/rtmp-servers/create - Start and verify ingestStart the server before the encoder connects and confirm the source is healthy.
POST /api/rtmp-servers/start - Create each platform destinationCreate one restream job per platform from the reviewed programme input.
POST /api/restream/create - Start multistream deliveryStart destinations independently so one platform does not hide another platform's state.
POST /api/restream/start - Create the service recordingBind a recording job to the same approved programme source.
POST /api/recording/create - Start archive captureStart capture after ingest is stable and retain the returned recording id.
POST /api/recording/start - Create church-site playbackConfigure the browser player and its intended viewer access.
POST /api/vod/create - Start and test playbackStart the player and test the viewer URL before publishing it.
POST /api/vod/start
Create and start each resource with the id returned by its own module. Validate the live input before enabling destinations, recording, or viewer playback.
Take a sports event from monitoring to paywall and replay
Compose a venue workflow that keeps the programme visible to operators, records the event, publishes browser playback, and starts controlled group access.
- Create venue ingestConfigure the RTMP entry point for the approved event programme.
POST /api/rtmp-servers/create - Start programme ingestStart the server and confirm contribution before downstream creation.
POST /api/rtmp-servers/start - Create operator monitoringAdd the programme and critical outputs to one event Multiview.
POST /api/multiview/create - Start the operator viewStart the wall and verify every required source before opening access.
POST /api/multiview/start - Create the event recordingConfigure capture from the approved programme input.
POST /api/recording/create - Start event captureStart recording after contribution and monitoring are healthy.
POST /api/recording/start - Finalize the recordingStop capture cleanly when the live event ends.
POST /api/recording/stop - Read replay mediaRead recordedFiles from the finalized recording before building replay.
POST /api/recording/getById - Create event playbackConfigure the live or replay player with the intended access settings.
POST /api/vod/create - Start viewer playbackStart the player and verify its viewer URL and runtime state.
POST /api/vod/start - Create controlled accessGroup the event player under the reviewed paywall or access policy.
POST /api/vod-group/create - Start the access groupStart the group only after playback and external entitlement checks are ready.
POST /api/vod-group/start
Stop and read the recording before treating it as replay media. A player group controls access to configured players; it does not replace payment-provider or entitlement validation outside Callaba.