The Wowza Streaming Engine REST API is an HTTP interface for configuring, managing and monitoring a Wowza Streaming Engine server. To make a request, identify the correct server and resource route, choose the method supported by that endpoint, set the content headers, and authenticate according to the server’s configuration.
Do not assume one sample URL, method or authentication setting applies to every installation. Use Wowza’s endpoint reference and the documentation for your installed version to verify the operation before sending a change.
Start with the resource you need to manage
The REST API exposes server management tasks as HTTP requests to resources. Depending on the task and route, you might retrieve information, create a resource, update a setting, trigger an action, or remove a resource. This is different from sending a live video stream: the API manages the Streaming Engine rather than carrying the stream itself.
Start by writing down the outcome you want in resource terms. For example, if you need to inspect or change an application, look for the application resource and the operation that supports the action. If you need server information, use the documented information route appropriate to your build. The route and supported methods depend on the resource; a method used for one application operation may not be valid for a different route.
Keep the distinction between Wowza Streaming Engine and Wowza Video clear. They are separate products with separate documentation, and an endpoint from one product’s API should not be copied into the other’s request. Check that the page you are consulting names the product and version you actually run.
For a YouTube channel operator, this API work is relevant when you administer a Wowza Engine server as part of a larger workflow, not as a shortcut for managing YouTube itself. If your immediate task is to check the broadcast without exposing it to viewers, a private YouTube live-loop test is a separate workflow with different controls.
Build the URL from the server and resource
Wowza’s overview documents this URL pattern: http://[your-wowza-server]:8087/v2/[path-to-resource]. The bracketed text is a placeholder, not a literal hostname or a universal path. Replace it with the address of the server you intend to administer and the resource path from the endpoint documentation.
The documented overview uses port 8087 for its REST API examples. Treat that as the documented pattern, then verify the port and whether the service is reachable at that address in your own installation. A proxy, firewall, customised configuration or a different environment can affect what address you should call. Do not expose a management interface publicly just to make a test convenient.
A route may contain identifiers such as a server name, virtual-host name and application name. Use the exact values that exist on your server. The public OpenAPI reference, for example, documents application routes under /v2/servers/{serverName}/vhosts/{vhostName}/applications. The braces indicate values to supply; they are not part of the concrete identifier. Consult the Wowza Streaming Engine REST API reference for the exact route and available operations.
A useful pre-request check is to separate the URL into parts: scheme and host, port, API version prefix, and resource path. Then compare each part with your server configuration and the reference. If a request returns a not-found response, check the resource spelling and identifiers before assuming that the API is unavailable. If it cannot connect, check the address, port, service availability and network path instead.
Do not guess an application endpoint from a name in the control panel. Start with the route template in the reference, substitute the server’s actual names, and then confirm whether the route represents a collection or one particular resource. That distinction often determines both the method and the shape of any request body.
Choose the method and request body
The overview describes the common method roles: GET retrieves information, POST creates records, PUT updates information or performs actions on existing records, and DELETE removes records. These descriptions help you interpret the reference; they are not permission to use every method on every route. Confirm the endpoint’s documented operation before sending a request.
| Intended task | Method to look for | Before sending |
|---|---|---|
| Read a resource or collection | GET |
Confirm what the response represents and whether the route is a collection or an individual resource. |
| Create a record | POST |
Check the required fields, accepted body format and whether the operation creates a new resource. |
| Change information or perform a documented action | PUT |
Verify whether the route expects a full resource representation, particular fields, or an action-specific body. |
| Remove a record | DELETE |
Confirm the target identifier and understand what the operation removes. |
The table is a starting point for reading the API documentation, not a universal mapping. The reference documents specific operations, including collection and individual application routes, and their supported methods differ. An action may have its own route and requirements. If the reference does not describe the method and body for your target, stop and find the operation-specific guidance rather than trying methods until one succeeds.
The request body also varies by operation. A retrieval may not need a body, while a create or update operation can require fields in a particular structure. Use the example associated with the endpoint as a guide, and check any required values, allowed values and response codes documented there. Do not reuse a body from another resource simply because both examples use JSON.
As a practical safeguard, make the first request a read-only one where possible. Inspect the current resource, record the values you plan to change, and test a change in a non-production environment if one is available. For a continuous YouTube broadcast, an unrelated server configuration change can affect a workflow overnight; the checks in a stable-source buffering guide can help distinguish a source problem from a management or delivery problem.
Set content headers for the format
Wowza’s examples use Accept and Content-Type headers to identify JSON or XML, with UTF-8 character encoding. The headers answer different questions: Content-Type describes the representation you are sending in a request body, while Accept describes the response representation you want to receive. Set them to match the endpoint’s supported formats and the body you have actually prepared.
For a JSON request, a request might use headers in this general shape:
Accept: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
This is a header illustration, not a complete request and not a claim that every endpoint accepts JSON. If you send XML, use the format and encoding documented for that operation instead. If the endpoint returns a response format other than the one you requested, check its documentation and the response headers before changing your client configuration.
A common mistake is to set the content type without supplying a body that is valid for that type. Another is to request one format but parse the response as another. When debugging, inspect the actual outgoing method, URL, headers and body, then compare them with the endpoint’s documentation. Keep credentials and sensitive body values out of shared logs.
If you are using curl, the exact quoting and line-continuation syntax can vary by shell, particularly between Unix-like shells and Windows command prompts or PowerShell. Treat a copied command as a template: quote JSON correctly for your shell, avoid putting a real password into a saved script, and verify the resulting request before using it against a live server.
Check the server’s authentication configuration
Wowza says a fresh installation uses basic authentication by default, but configuration can differ. In production, keep authentication enabled. Do not copy a test setup that disables authentication as a convenient way to make a request succeed.
With basic authentication, the username and password are Base64-encoded in the request. Base64 is an encoding, not encryption, so Wowza says this is not considered secure unless used over HTTPS. Use a protected connection and follow the current security guidance for your installed version. Never send administrator credentials across an untrusted network in plain HTTP.
Wowza documents several authentication methods: basic, digest, digestfile, remotehttp and none. Which method is configured, and which password encoding it supports, matters to whether a client can authenticate. The authentication guide associates basic with plaintext or bcrypt, digest and digestfile with md5 or sha256, and lists remote HTTP and none without a password encoding. These are configuration details, not a recommendation to change a working server blindly. Consult the Wowza authentication documentation and confirm current behaviour for your version.
The guide recommends sha256 over md5 because of potential vulnerabilities in md5, while also giving qualifications around version and client compatibility. It documents sha256 support in Wowza Streaming Engine 4.8.19 and later, and notes a Firefox limitation in the specific digest configuration described there; that statement should not be broadened into a claim about all browsers or all authentication modes. Wowza Streaming Engine Manager support and API-client behaviour should be checked in the same configuration context.
Version qualifications matter elsewhere too. The authentication guide says Wowza Streaming Engine 4.8.8.01 and later allows digest or bcrypt hashes in admin.password. If your installed version is older, or if you have a custom authentication setup, do not assume those options are available. Confirm the current official documentation and test the client with the actual configured method.
The none method is not a production shortcut. Wowza warns that choosing it also disables authentication for Wowza Streaming Manager and removes the ability to manage and configure the media server through that manager. Remote HTTP authentication has its own requirements, including a configured remote URL, shared secret and identity; the remote endpoint must accept POST requests. Treat either configuration as a deliberate administrative change, not an adjustment to make a failed API call disappear.
Confirm the endpoint-specific operation
Once you know the resource, use the reference to confirm the exact method, path parameters, body schema and response. The public OpenAPI reference documents route families and operations. For application resources, it lists collection operations as well as operations on individual applications and a documented PUT action route. Those examples show why a route family is not enough: the collection and a specific application can have different supported actions.
Read the operation description and any required parameters before forming a request. Check whether a field is required, whether a path value is a server, virtual host or application identifier, and whether the operation changes state. Note any version, build or configuration conditions. The endpoint reference is the authority for the precise route; do not infer a path by concatenating words from a user interface.
Wowza also documents a GET /restinfo operation, with availability limited to builds 15089 or later. Its returned information includes items such as API version, server name, version, REST build and licence validity. Check the build qualification before relying on it, and verify its current documented output rather than designing automation around an assumed response.
For local discovery, Wowza’s Postman procedure describes retrieving http://localhost:8089/swagger.json from a local documentation servlet after enabling and configuring it and restarting the server. The procedure requires Wowza Streaming Engine 4.5.0 or later. This is a way to inspect documentation, not the REST API request base URL: the overview’s REST examples use port 8087. Keep those two ports and purposes distinct, and follow the setup steps for the version you run.
The public reference is useful when you need to browse routes without access to the server’s local documentation servlet. The local Swagger/Postman flow can be useful when it is enabled and available on the server. Neither removes the need to verify that an operation matches your installed version and configuration. Wowza’s query examples can illustrate workflows, but use them as examples to interpret alongside the endpoint reference, not as universal request recipes.
Test and monitor requests safely
Before sending a write operation, confirm that you have the intended server, route, method and authentication context. Prefer a read request first, and capture the current configuration so you can compare results. If possible, test the proposed operation on a non-production instance. Avoid running an uncertain DELETE or update against a production application merely to see what the endpoint does.
After a request, inspect the HTTP status, response body and relevant server logs. A successful HTTP response tells you that the request was accepted at the API layer; it does not by itself prove that a downstream playback or publishing workflow is healthy. Conversely, an authentication failure points you towards configured credentials and method compatibility, while a malformed-request response suggests checking the method, headers, body format and required fields. Use the specific response and endpoint documentation rather than applying a single diagnosis to every error.
Keep a small change record: the time of the change, resource affected, request purpose, response and any rollback action. Redact passwords, tokens and other sensitive values before saving or sharing a curl transcript, Postman collection or log. A working request should not leave an administrator credential embedded in a repository or support ticket.
Monitoring should cover both the API action and the outcome you care about. If an API call changes a source or application setting, confirm that the server reports the expected configuration and separately verify the stream or player behaviour. When your goal is to keep a prerecorded channel running without keeping a workstation on, that is a different operating model: StreamNeo removes the specific burden of leaving your own computer running by turning an uploaded file into a YouTube live stream, with the broadcast monitored and restarted if it drops.
For YouTube-facing tests, keep the broadcast private or otherwise controlled until you have checked playback, audio and the intended loop. A guide to running a prerecorded temple livestream covers that channel-side workflow; it does not replace Wowza’s API reference when you are changing an Engine resource.
Make a request checklist before automation
Before turning a successful manual request into a script, write down its assumptions. Record the server address and API version prefix, the endpoint source you consulted, the concrete resource identifiers, supported method, body format, required headers and configured authentication method. Note the Wowza version or build condition if the operation depends on one. This turns a one-off request into something another administrator can review without guessing what the placeholders meant.
Keep environment-specific values outside the request logic where practical. Development and production servers may have different addresses, resource names, authentication arrangements and certificates. A script should not quietly point at a production host because an old URL was copied into it. Before running an automated write operation, print or log the non-sensitive target details so you can verify the destination; do not print the password or other secret.
Handle failure explicitly. A network error, authentication rejection, invalid request and server-side failure are different cases, and blindly retrying a write operation can repeat an action or create duplicate records. Read the endpoint’s behaviour and response guidance, and decide which failures are safe to retry. Where the operation’s effects are unclear, stop for review rather than looping through requests.
Finally, re-check the official documentation when you upgrade Wowza or change authentication configuration. A request that works in one version may rely on an endpoint, password encoding or documentation procedure that differs in another. Automation is useful only when its assumptions remain visible and current.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I make a REST API request to Wowza Streaming Engine?
Build the URL from your server address and the documented /v2/ resource path, then use the method, headers and body specified for that endpoint. Authenticate using the method configured on your server, and verify the result from the response and server state. The overview’s pattern is a guide, not a complete request for every installation.
How do I authenticate Wowza Streaming Engine REST API calls?
First check the server’s configured authentication method and password encoding, then configure your client to match. Wowza describes basic authentication as the default for a fresh installation, but settings can change; keep authentication enabled in production and use HTTPS where basic authentication is used. Confirm version and client qualifications in the official guide.
Where do I find the endpoint for an application?
Use the application route family in Wowza’s public OpenAPI reference, then substitute the actual server, virtual-host and application identifiers shown for your installation. Check the individual operation for its supported method, required parameters and body. Do not infer an endpoint from a control-panel label alone.
Is port 8089 the Wowza REST API port?
The documented REST API overview uses port 8087 in its URL pattern and examples. Wowza’s Postman guide uses port 8089 for retrieving a local Swagger documentation file after the documentation servlet is configured and enabled. Verify your installation and keep the API request URL distinct from the documentation-discovery URL.