media server logo
Toggle documentation navigation
Callaba home

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.

What it doesFrom product task to API request

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.

1Choose an outcome2Open the module3Send a request

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-token header 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

  1. Create an SRT or RTMP server for the contribution feed.
  2. Create a recording or restream that uses the server as its input.
  3. Create a web player when the output must be viewed in a browser.
  4. Start the resources in dependency order and check their runtime status.
  5. 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.

Multi-module 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.

  1. Create SRT ingestConfigure the listener, latency, access rules, and source routing.POST /api/srt-servers/create
  2. Start and verify ingestStart the server before creating jobs that depend on its live input.POST /api/srt-servers/start
  3. Create the archive jobChoose the SRT server input preset and the required continuous or segmented output.POST /api/recording/create
  4. Start recordingStart capture only after the contribution input is healthy.POST /api/recording/start
  5. Create browser deliveryUse the SRT server input preset, then configure HLS or DASH and viewer access.POST /api/vod/create
  6. 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.