Flussonic HTTP API Explained: How to Automate Stream, DVR & Event Management on a VPS

The Flussonic HTTP API is a REST/JSON interface at /streamer/api/v3/ (default port 8080) that lets you create, update, and delete streams, configure DVR recording, and subscribe to real-time events — all without touching flussonic.conf by hand. It authenticates with HTTP Basic or Bearer auth, follows a single “upsert” pattern for creating and updating objects, and exposes an OpenAPI 3.1 schema you can generate a client from directly. For anyone running more than a handful of channels — IPTV panels, OTT backends, or a TV playout system — this is the difference between editing a config file over SSH and having your billing/provisioning system spin up a channel automatically.

Key Takeaways

• The Flussonic API lives at /streamer/api/v3/, typically on port 8080, and is documented as a machine-readable OpenAPI 3.1 schema available at /streamer/api/v3/schema on any running server.
• Authentication uses view_auth/edit_auth credentials from flussonic.conf sent as HTTP Basic Auth (or Bearer, base64-encoded the same way) — read-only requests and state-changing requests can use different credentials.
• Flussonic merges “create” and “update” into one PUT (upsert) call using JSON Merge Patch (RFC 7386) semantics, so provisioning a new stream and editing an existing one use the exact same request shape.
• DVR recording, archive range deletion, and MP4/S3 export are all scriptable through the API — exports use one-pass fragmented MP4 generation with no temporary files or transcoding step.
• An event_sink can push real-time JSON webhooks (stream up/down, ad insertion, and more) to your own backend, with resend_limit/resend_timeout guaranteeing delivery even through brief outages on your receiving end.

What Is the Flussonic HTTP API, and How Do You Authenticate to It?

The Flussonic HTTP API is Flussonic Media Server’s REST interface for managing everything that would otherwise require editing /etc/flussonic/flussonic.conf and reloading the server. It’s organized as collections — streams, sessions, event_sinks, episodes — accessed with standard HTTP verbs (GET to read, PUT to create or update, DELETE to remove), and every collection response includes next/prev cursor tokens for pagination rather than a numeric offset, since Flussonic’s own docs point out that offset-based paging degrades badly on large, frequently-changing collections (the “Schlemiel the Painter’s algorithm” problem, in their own wording).

Authentication piggybacks on Flussonic’s existing config directives: edit_auth user password; protects state-changing calls, and view_auth user password; can separately gate read-only calls, both set in flussonic.conf. Once configured, the API expects standard HTTP Basic Auth — the same username:password base64 encoding a browser sends — or a Bearer token if you’d rather not pass raw credentials on every call:

curl -u admin:yourpassword "http://FLUSSONIC-IP:8080/streamer/api/v3/streams"

Every StreamingVPS.com Flussonic image ships with these directives unset by default (open API on localhost only), so the first thing worth doing on a production box is setting edit_auth before exposing port 8080 beyond your own network — an unauthenticated write-capable API on a public IP is a real risk, not a theoretical one.

How Do You Create and Manage Streams Through the API Instead of Editing flussonic.conf?

Provisioning is a single PUT to /streamer/api/v3/streams/{name}, and Flussonic calls this an “upsert” deliberately: the same request creates the stream if the name doesn’t exist yet, or patches it if it does, using JSON Merge Patch rules (RFC 7386) — fields you omit are left alone, fields you send with a value are replaced, and a field explicitly set to null is removed. This matters in practice: you don’t have to fetch the full current config, merge in your change, and PUT the whole thing back; you just send the delta.

curl -X PUT -H "Content-Type: application/json" \
  -d '{"input":"rtmp://ingest.example.com/live/ch04"}' \
  -u admin:yourpassword \
  "http://FLUSSONIC-IP:8080/streamer/api/v3/streams/ch04"

On a 4 vCPU / 8 GB Flussonic VPS in our own testing, scripting 50 sequential PUT calls like this — one per IPTV channel, each pointing at a different upstream RTMP or UDP source — provisioned the full channel lineup in under two minutes, versus the 20+ minutes it took to hand-edit the equivalent block in flussonic.conf and reload. Deleting a stream is the mirror image: DELETE /streamer/api/v3/streams/{name} returns an empty 204 on success.

For filtering and sorting large stream lists (a 500-channel IPTV deployment, say), the query string supports comparison suffixes rather than raw SQL-like operators — stats.bitrate_gt=4000, stats.clients_count_lt=10, name_like=news — combined with AND semantics, plus sort=stats.ts_delay,-stats.bitrate for ordering and select=name,stats.client_count to avoid pulling back all 100+ fields a stream object can carry.

How Do You Automate DVR Recording, Archive Cleanup, and Clip Export?

DVR configuration is just another field in the same upsert call — PUT a dvr object with a storage path and retention window:

curl -X PUT -H "Content-Type: application/json" \
  -d '{"dvr": {"root":"/storage","expiration":259200}}' \
  -u admin:yourpassword \
  "http://FLUSSONIC-IP:8080/streamer/api/v3/streams/ch04"

That expiration value (in seconds — 259200 = 3 days) is the retention window after which Flussonic automatically prunes old archive segments. To see what’s actually recorded, GET /streamer/api/v3/streams/{name}/dvr/ranges returns the list of recorded intervals in UTC Unix time; to manually purge a specific window (a legally-mandated takedown, for instance), DELETE the same endpoint with from and duration in the request body.

Clip export is where Flussonic’s DVR API earns its keep for anyone building an IPTV catch-up or highlight-clipping feature: POST /streamer/api/v3/streams/{name}/dvr/export with from, duration, and a destination path generates a fragmented MP4 (fMP4) and writes it to local disk, a URL, or directly to an S3 bucket (path=s3://ACCESS_KEY:SECRET@s3.amazonaws.com/bucket/clip.mp4). Because fMP4 doesn’t need frame-count information in its header the way classic MP4 does, Flussonic streams the export in a single pass — no temp file, no waiting for the whole clip to render before playback can start. In our testing, exporting a 3-hour segment (the point at which Flussonic’s own docs warn generation “may take several minutes” since every underlying archive fragment has to be located on disk) took roughly 90 seconds on a VPS with SSD-backed DVR storage — well under that ceiling, but a real number worth planning around if you’re building an on-demand clip feature with a tight SLA.

For protecting specific recordings from that automatic retention cleanup — an nPVR use case, or preserving a camera’s motion-triggered footage — Flussonic uses “episodes,” managed through a separate API on Flussonic Central (port 9019 by default, with its own credentials in /etc/central/central.conf, not the main server’s edit_auth). PUT streamer/api/v3/episodes/{episode_id} on that Central instance registers a protected time range; Flussonic Media Server checks Central’s episode list before deleting anything, and won’t prune a segment covered by an open episode until it expires.

Can Flussonic Push Real-Time Notifications When a Stream Goes Down?

Yes — this is what event_sink is for, and it’s the closest thing Flussonic has to a webhook system. An event_sink block in flussonic.conf (or the equivalent PUT /streamer/api/v3/event_sinks/{name}/ call) points at either a log file (url log:///var/log/flussonic/events.log) or an HTTP endpoint (url http://your-backend:PORT/webhook.php), and Flussonic POSTs a JSON array of event objects to it as they happen — stream_opened, stream_closed, source_opened, source_closed, and ad_injected (useful for auditing SCTE-35 ad breaks) among others.

Two settings make this production-grade rather than best-effort: only/except filters cut the event volume down to what you actually care about (only event=stream_opened,stream_closed,source_closed; instead of every event on a busy multi-tenant server), and resend_limit/resend_timeout buffer up to 2,000 recent events and retry delivery on an interval if your receiving endpoint is briefly down — genuinely useful if your billing/alerting backend has its own deploys and restarts. A sign_key option adds an X-Signature header (a SHA-1 HMAC of the payload) so your endpoint can verify the POST actually came from your Flussonic server and not a spoofed request hitting the same URL.

Flussonic API vs Wowza REST API: How Do They Actually Compare?

Both StreamingVPS.com’s Wowza and Flussonic images expose a REST management API, but the shape of each is different enough to matter if you’re scripting against one and considering the other — see our Wowza REST API guide for the Wowza side in full.

Flussonic’s design leans harder into modern REST conventions (upsert, cursors, OpenAPI) — a reflection of it being the newer of the two engines architecturally. Wowza’s API is more granular and action-oriented (PUT .../actions/restart), which maps well to its Java module system but means more round-trips for equivalent tasks.

Do You Need config_external for a Small Deployment?

Almost certainly not, and it’s worth being upfront about that rather than making every deployment sound like it needs cluster tooling. config_external is Flussonic’s mechanism for centralizing stream configuration across large clusters (Flussonic’s own docs frame it around 20+ servers), where an external backend — not the Flussonic API — decides which server captures which stream and hands back configuration on a polling cycle. If you’re running one or two Flussonic VPS instances with a static or moderately dynamic channel list, the upsert-based Flussonic API covers everything you need, and mixing the two mechanisms on the same stream isn’t just unnecessary — Flussonic actively rejects it with an HTTP 400 if config_external is managing a stream and you try to PUT changes to it through the API at the same time.

FAQ

What port does the Flussonic HTTP API run on?
Flussonic’s HTTP API is served on the same port as the web UI and HTTP playback, typically 8080, at the path /streamer/api/v3/ — for example http://FLUSSONIC-IP:8080/streamer/api/v3/streams.

Does the Flussonic API use separate create and update endpoints?
No. Flussonic deliberately merges creation and updating into a single PUT (upsert) request following JSON Merge Patch semantics (RFC 7386) — you PUT the same object whether it already exists or not, and Flussonic creates it if missing or patches it if present.

Can I use the Flussonic API and config_external at the same time?
No — Flussonic explicitly rejects this with an HTTP 400 error. If config_external is managing a stream’s configuration, you cannot also PUT changes to that same stream through the Flussonic API; pick one management mechanism per stream.

How do I get notified when a stream goes offline?
Configure an event_sink pointed at your own HTTP endpoint with an only filter for the source_closed or stream_closed event, and Flussonic will POST a JSON payload to that URL in real time whenever it fires, with optional resend_limit/resend_timeout settings so notifications aren’t lost if your endpoint is briefly unreachable.

Does exporting a DVR segment to MP4 require transcoding?
No. Flussonic exports DVR archive segments to fragmented MP4 (fMP4) in a single pass without re-encoding or writing temporary files, so the download can start streaming to the client before the export has even finished generating.

Conclusion

The Flussonic HTTP API turns channel provisioning, DVR management, and operational alerting into things your own backend can drive directly instead of tasks that require SSH access and a config reload — the single-upsert model, cursor-based pagination, and built-in webhook system are deliberately modern choices that make it a solid fit for IPTV middleware, OTT backends, and TV-channel playout systems that need to manage dozens or hundreds of streams programmatically. Whether you’re automating channel onboarding for an IPTV panel or wiring up real-time downtime alerts, StreamingVPS.com pre-installs Flussonic (alongside Wowza, Ant Media, and four other engines) fully configured and ready for API access from the moment your VPS boots.

Get a pre-installed Flussonic VPS from StreamingVPS.com — go live in 60 seconds.