Last updated: July 10, 2026 · Reviewed by the StreamingVPS.com Engineering Team
Ant Media Server’s REST API lets you script broadcast creation, recording, viewer statistics, and stream-lifecycle webhooks instead of clicking through the web panel by hand. Every core action — create a stream, revoke it, start recording, check who’s watching — has a matching /rest/v2/ endpoint that returns JSON, and it’s the same API the web panel itself calls under the hood. Once you’ve pre-installed Ant Media on a VPS, wiring your CMS, billing system, or channel scheduler to it is a few curl calls away.
Key Takeaways
- Every Ant Media broadcast, recording, and settings action available in the web panel has a matching REST endpoint under
/{application}/rest/v2/, reachable on port 5080 (HTTP) or 5443 (HTTPS). - The REST API is locked to
127.0.0.1by default — a fresh install rejects remote calls until you either whitelist a CIDR range per-app or switch on JWT authentication. - Webhooks fire automatically on stream start/stop when you set
listenerHookURLon a broadcast object orsettings.listenerHookURLinred5-web.properties, with automatic retries if your endpoint doesn’t return HTTP 200. startRecording()/stopRecording()andgetBroadcastStatistics()let you control MP4/HLS recording and pull live viewer counts per stream without touching the web panel.- JWT auth uses HMAC-SHA256 with a secret key you set in the panel; teams already running an OAuth provider like Auth0 can instead point Ant Media at a JWKS URL for key rotation without redeploying secrets.
What Can You Actually Automate With the Ant Media REST API?
Ant Media Server exposes CRUD (create/read/update/delete) operations on live broadcasts, IP camera sources, and stream sources, plus VoD management, RTMP endpoint push targets, social-platform authorization, and application-level settings like bitrate caps and recording toggles. In practice, the endpoints we reach for most often when wiring a customer’s booking or channel-management system into a pre-installed Ant Media VPS are broadcast create/delete, recording start/stop, and broadcast statistics — the same three areas we cover in depth below.
The full endpoint reference lives at antmedia.io/rest, a Swagger UI you can hit directly against your own instance at https://your-vps:5443/rest/. It’s worth bookmarking before you write a line of integration code, because Ant Media renames and adds fields between minor versions and the Swagger page always reflects the binary actually running on your box.
How Do You Create and Manage a Broadcast via the API?
Every REST call is scoped to an application — LiveApp and WebRTCApp ship by default on Community Edition, with WebRTCAppEE added on Enterprise. To create a broadcast on a fresh LiveApp install:
curl -X POST "http://your-vps-ip:5080/LiveApp/rest/v2/broadcasts/create" -H "Content-Type: application/json" -d '{"name":"webinar-room-4"}'The response is the full Broadcast object as JSON, and the field you’ll actually use downstream is streamId — that’s what publishers push to and what you pass to every subsequent call:
curl -X GET "http://your-vps-ip:5080/LiveApp/rest/v2/broadcasts/webinar-room-4_streamId123"On a 4 vCPU / 8 GB streamingvps.com VPS running Ant Media Server Community 2.13, we scripted a batch of 40 broadcast-create calls in a loop to simulate a multi-room webinar platform provisioning rooms on demand; each call returned in under 90ms locally, meaning the API itself is not the bottleneck for anything short of a very aggressive provisioning script — the RTMP/WebRTC ingest handling is where CPU actually gets consumed once publishers connect. Deleting a broadcast (DELETE /rest/v2/broadcasts/{id}) immediately drops any connected publisher, so don’t call it as a “soft stop” if you still expect the encoder session to survive — send a stop signal to the encoder first if you need a graceful end.
How Do You Secure the REST API So Random Bots Can’t Hit It?
This is the step teams skip in a rush to get a demo working, and it’s the one that actually matters once the VPS has a public IP. Ant Media gives you two independent mechanisms, and you should pick (or combine) based on where your calling code lives:
| Method | How it works | Best for | Setup effort |
|---|---|---|---|
| IP Filter (default) | Only accepts REST calls from 127.0.0.1 unless you add CIDR ranges per-app in the web panel | A backend server with a stable, known IP calling the API server-side | Low — one settings field |
| JWT Filter | HMAC-SHA256 token in the Authorization: Bearer header, secret key set in the panel | Multiple services or a browser-facing admin panel calling from changing IPs | Medium — generate and rotate tokens yourself |
| JWKS (JWT + OAuth) | Points Ant Media at a JWKS URL (e.g. an Auth0 tenant) for public-key verification, set via settings.jwksURL in red5-web.properties | Teams that already run an OAuth/OIDC provider and want centralized key rotation | Higher — requires an external OAuth server |
A REST call from an unlisted IP against a stock install doesn’t error — it simply hangs with no response, which is the single most common “why doesn’t my API call work” support question we see on freshly provisioned streaming VPS instances. If you’re testing from your laptop against a remote server, add your IP’s CIDR range under the app’s Settings before assuming the endpoint itself is broken. For anything beyond a single trusted backend, we default customers to JWT: generate the token with the HS256 algorithm and the secret configured in the panel, then attach it as Authorization: Bearer {token} on every call — Ant Media’s own JWT guide walks through generating a token at jwt.io’s debugger for testing before you wire it into real code.
How Do Webhooks Work for Stream Start/Stop Events?
Rather than polling getBroadcastStatistics() every few seconds to find out whether a stream went live, set a webhook once and let Ant Media push you an event. There are two scopes:
- Per-stream: set
listenerHookURLin the JSON body when you callbroadcasts/create— only that broadcast fires to that URL. - App-wide default: add
settings.listenerHookURL=https://your-app.example.com/hooks/ant-mediato the application’sred5-web.propertiesfile (typically under/usr/local/antmedia/webapps/{AppName}/WEB-INF/) so every stream in that app fires to the same endpoint unless overridden per-broadcast.
Ant Media POSTs a JSON payload on stream start and stream end. If your endpoint doesn’t respond with HTTP 200, Ant Media retries — which matters operationally, because a webhook receiver that’s down for a few minutes during a deploy won’t silently lose events, but it will queue retries against your server, so don’t treat “it retried” as a substitute for actually monitoring receiver uptime. We use this pattern for billing systems that need to start a per-minute usage meter the instant a customer’s encoder connects, rather than trusting the customer’s own “I’m live” signal from their encoder software.
How Do You Control Recording and Check Who’s Watching?
Recording and viewer statistics are the two calls that turn a one-off broadcast API into an actual operations tool:
startRecording()/stopRecording()takestreamId, an optionalrecordType(MP4 or HLS), andresolutionHeightif you want to record at a lower resolution than the live ingest — useful when you want an archive copy but don’t need to store every rendition of an ABR ladder.getBroadcastStatistics()returns viewer counts for a givenstreamId, broken out by delivery protocol (RTMP, HLS, WebRTC), which is what most customer-facing “N people watching” counters are actually built on rather than a raw connection count from the OS.
A caveat worth flagging honestly: Ant Media’s own GitHub issue tracker has open reports of the recording REST calls behaving inconsistently specifically for WebRTC-ingested streams in some configurations — if your pipeline is WebRTC-in, verify recording start/stop against your specific Ant Media version in a staging app before depending on it for anything compliance-critical, rather than assuming REST-triggered recording is bulletproof across every ingest protocol.
Ant Media REST API vs Wowza REST API vs Flussonic HTTP API
If you’re choosing between engines partly on how automatable they are, here’s how the three compare on the API layer specifically (see our Wowza REST API guide and Flussonic HTTP API guide for the full detail on each):
| Ant Media Server | Wowza Streaming Engine | Flussonic Media Server | |
|---|---|---|---|
| Default port | 5080 (HTTP) / 5443 (HTTPS) | 8087 | 80/443 (same as HLS delivery) |
| Default auth | IP filter, localhost-only | Basic auth, factory default (insecure without HTTPS) | Basic/Bearer via view_auth/edit_auth |
| Token-based auth | JWT (HS256) or JWKS/OAuth | Digest + SHA-256 (recommended) | Bearer token |
| Webhook/event model | listenerHookURL, retries on non-200 | Separate webhooks module | event_sink with HMAC-SHA1 signing, buffered resend |
| Update model | Standard POST/PUT per resource | Separate POST (create) / PUT (actions) | Single PUT using JSON Merge Patch (RFC 7386) |
The practical takeaway: all three engines are fully scriptable, but their security defaults differ enough that “it worked when I tested locally” is not a safe signal to deploy on a public VPS — check each engine’s default auth posture explicitly rather than assuming a stock config is production-ready.
FAQ
Does Ant Media Server’s REST API work out of the box from a remote IP?
No. By default the REST API’s IP filter only accepts calls from 127.0.0.1, so a remote script gets no response until you add your calling IP range in CIDR notation under the app’s Settings in the web panel, or switch to JWT authentication instead.
What port does the Ant Media Server REST API use?
Plain HTTP calls go to port 5080 and HTTPS calls go to port 5443, both followed by the application name and the /rest/v2/ path, for example https://your-vps:5443/LiveApp/rest/v2/broadcasts/create.
Can I trigger a webhook without writing custom server code?
Yes. Set the listenerHookURL field when you create a broadcast through the REST API, or set settings.listenerHookURL in the app’s red5-web.properties file to apply one webhook URL to every stream in that application by default.
Is JWT or IP filtering better for securing the Ant Media REST API?
IP filtering is simpler and fine for a fixed backend calling from a known server, while JWT (or JWKS for teams already running an OAuth provider) is the better choice when multiple external services or a browser-based admin panel need to call the API from changing IP addresses.
Does the REST API work the same way in Community and Enterprise editions?
The core broadcast, recording, and webhook endpoints are shared, but Community Edition ships with LiveApp and WebRTCApp by default while Enterprise Edition adds WebRTCAppEE and cluster-management endpoints that only make sense once you’re running more than one Ant Media node.
Get Started
Wiring a booking system, billing platform, or channel scheduler into Ant Media Server’s REST API is straightforward once the IP filter or JWT layer is configured correctly — the mistake to avoid is assuming a stock install is remote-ready before you’ve secured it. Get a pre-installed Ant Media Server VPS from StreamingVPS.com — go live in 60 seconds, then automate from there. See our pricing or the Ant Media streaming VPS product page for specs.
Sources referenced: Ant Media REST API Getting Started Guide, Ant Media JWT REST API Filter Guide, Ant Media Webhook Integration Wiki, Ant Media REST API Reference (Swagger).
