Wowza Streaming Engine REST API: How to Automate Application, Stream & Server Management on a VPS

Last updated: July 7, 2026 | Author: StreamingVPS.com Engineering Team (reviewed)

The Wowza Streaming Engine REST API is a built-in HTTP interface, listening on port 8087, that exposes every configuration and monitoring action available in the Wowza Manager UI as a scriptable GET/PUT/POST/DELETE call. In practice that means you can create a new live application, restart it, or pull real-time viewer counts with a single curl command instead of clicking through a browser dashboard. It’s enabled on every fresh Wowza install with HTTP Basic authentication turned on by default — which is exactly the setting most operators need to change before going to production.

We manage Wowza on hundreds of pre-installed VPS instances at StreamingVPS.com, and the REST API is the single biggest lever for anyone running more than a handful of live applications: autoscaling scripts, uptime dashboards, and CI/CD-style config deployment all hook into it instead of a person clicking buttons at 2 a.m.

Key Takeaways

• The REST API lives at http://[your-server]:8087/v2/[path-to-resource] and mirrors nearly every action available in the Wowza Streaming Engine Manager UI.
• Authentication is controlled by the <RESTInterface> block in Server.xml and supports none, basic, digest, digestfile, or remotehttp — the factory default is basic, which Wowza itself says isn’t secure without HTTPS.
• Core automation building blocks: POST to .../applications/{appName} creates an app, PUT .../actions/restart restarts it, and GET .../monitoring/current returns live per-protocol connection counts.
• Port 8087 should never be open to the public internet — restrict it to localhost, a VPN, or an SSH tunnel, and switch authentication to digest with SHA-256 before any production use.
• An official free PHP client (wse-rest-library-php) exists if you’d rather not hand-roll curl and JSON parsing yourself.

What Is the Wowza Streaming Engine REST API, Exactly?

Every Wowza Streaming Engine server exposes a versioned REST API under /v2/. Resource paths follow a predictable pattern built from placeholders:

http://localhost:8087/v2/servers/{serverName}/vhosts/{vhostName}/applications/{appName}

{serverName} defaults to _defaultServer_ and {vhostName} defaults to _defaultVHost_ on a standard install, so a real request against an application named live looks like:

http://localhost:8087/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/live

The API supports both JSON and XML payloads (set via the Accept and Content-Type headers), and covers far more than applications — dedicated resource groups exist for server licenses, virtual hosts, MediaCache, the transcoder, stream targets (push-publishing/restreaming destinations), server users, and webhooks. If you’ve configured any of those through the Wowza Manager UI, there’s a matching API path for it.

This is distinct from Wowza’s stream-start/stop webhooks (event notifications pushed out to your app when a stream begins or ends) — the REST API is the pull/command side: you’re asking Wowza questions or telling it to do something, rather than Wowza telling you something happened.

How Do You Authenticate REST API Requests?

Wowza’s Server.xml config file (in [install-dir]/conf/) contains a <RESTInterface> block with an <AuthenticationMethod> property that accepts five values: none, basic, digest, digestfile, or remotehttp. A fresh install ships with basic enabled.

Basic authentication Base64-encodes the username and password in each request — encoded, not encrypted — so Wowza’s own documentation flags it as unsafe unless paired with HTTPS. For anything beyond a local dev sandbox, switch to digest authentication with SHA-256 password hashing (Wowza explicitly recommends SHA-256 over MD5 given known MD5 weaknesses). A digest-authenticated curl request looks like:

curl -X GET \
  --digest -u "apiuser:apipassword" \
  -H 'Accept:application/json; charset=utf-8' \
  "http://localhost:8087/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/live/monitoring/current"

On the streaming VPS instances we manage, we additionally bind the REST listener to localhost or a private VLAN and reach it over an SSH tunnel for anything scripted from outside the box — belt-and-suspenders on top of digest auth, since a misconfigured firewall rule is a one-line mistake away from exposing a management interface to the internet.

How Do You Create and Restart an Application via the API?

Creating a new live application is a single POST with a JSON body describing the app:

curl -X POST \
  --digest -u "apiuser:apipassword" \
  -H 'Content-Type:application/json; charset=utf-8' \
  -d '{"name":"live2","appType":"Live","description":"Auto-provisioned by deploy script"}' \
  "http://localhost:8087/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications"

A successful call returns {"success": true, "message": "Application (live2) created successfully."}. Restarting an existing application — useful after you’ve pushed a config change and don’t want to bounce the whole Wowza process — is a PUT against an /actions/ sub-path:

curl -X PUT \
  --digest -u "apiuser:apipassword" \
  -H 'Accept:application/json; charset=utf-8' \
  "http://localhost:8087/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/live2/actions/restart"

This is the pattern we lean on for tenant-provisioning scripts: a signup event on the customer-facing side triggers a POST that spins up an isolated Wowza application per customer, with no manual step in between. On a 4 vCPU / 8 GB StreamingVPS Wowza instance we’ve scripted this to provision and restart a new isolated application in well under two seconds end-to-end, which is fast enough to do synchronously in a signup flow rather than queuing it.

How Do You Pull Live Stream Stats Through the API?

The monitoring/current endpoint is the workhorse for dashboards and alerting:

curl -X GET \
  --digest -u "apiuser:apipassword" \
  -H 'Accept:application/json; charset=utf-8' \
  "http://localhost:8087/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/live/monitoring/current"

The response includes a connectionCount object broken out per delivery protocol, for example:

"connectionCount": {
  "RTMP": 42,
  "CUPERTINO": 118,
  "MPEGDASH": 31,
  "SMOOTH": 0,
  "RTP": 0,
  "WEBM": 0,
  "DVRCHUNKS": 6
}

You can drill in further to a specific incoming stream with /instances/{instanceName}/incomingstreams/{streamName}/monitoring/current, which is what we use internally to detect a source encoder that’s dropped without waiting for a viewer complaint. Wowza also exposes a lighter-weight legacy alternative — the HTTPConnectionCountsXML HTTP provider on the administrative port (typically 8086) — if you only need aggregate connection counts in XML and don’t want to authenticate against the full REST API.

At the scale we run (dozens of concurrent applications per box on our higher-tier VPS plans), polling monitoring/current across every application every 5 seconds adds negligible measured CPU overhead — it’s reading in-memory counters, not querying a database — so it’s safe to poll aggressively for a real-time dashboard rather than settling for a 1-minute cron.

Is It Safe to Expose Port 8087 to the Internet?

No — and this is the mistake we see most often on self-managed VPS boxes. Port 8087 is a management interface: anyone who can reach it and authenticate can create applications, delete them, or read live viewer/connection data. Wowza’s own hardening guidance is consistent with general server-security practice for any admin API:

If you’ve already read our firewall ports guide, the same logic applies here: 1935 (RTMP) and your HLS/DASH delivery ports are meant to be public, 8087 is not.

Wowza REST API vs. the Manager UI vs. Third-Party Orchestration

For a single-server setup, the REST API called directly from a shell script or small Python service is usually the sweet spot — enough automation to eliminate manual clicking, without the overhead of a full infrastructure-as-code pipeline.

FAQ

Is the Wowza REST API included with every Wowza Streaming Engine license?
Yes. It ships as a built-in part of every installation on port 8087, with no separate add-on or license tier required.

What port does the Wowza Streaming Engine REST API use?
Port 8087, via http://[your-server]:8087/v2/[path-to-resource] — separate from RTMP (1935) and your HLS/DASH delivery ports.

Can I use the REST API to see live viewer counts?
Yes. GET .../applications/{appName}/monitoring/current returns a connectionCount object broken out by protocol (RTMP, CUPERTINO/HLS, MPEGDASH, RTP, and more), which you can poll on an interval.

Is it safe to expose port 8087 to the public internet?
No. Keep digest authentication (SHA-256) enabled and restrict access at the firewall to trusted IPs, an SSH tunnel, or a VPN — basic auth alone only encodes credentials rather than encrypting them.

Do I need to write raw curl commands, or is there a client library?
Wowza publishes a free, official PHP client (wse-rest-library-php on GitHub); the JSON responses are also simple enough to consume from Python, Node, or any HTTP client without a library at all.

Get Started

Wowza’s REST API turns application provisioning, restarts, and live monitoring into something you script once and forget, instead of a manual task that doesn’t scale past a handful of streams. Every Wowza VPS from StreamingVPS.com comes with Wowza Streaming Engine pre-installed and the REST API listening out of the box — you just need to lock down the firewall rule and pick your authentication method. Get a pre-installed Wowza VPS from StreamingVPS.com — go live in 60 seconds, and see pricing for current plans.

Related reading: Wowza Transcoder Explained, Wowza Stream Targets (push publishing), Live Stream Webhooks, Streaming Server Firewall Ports.