“Wowza Streaming Cloud” is the legacy name many tutorials still use; the current documentation describes Wowza Video and marks API v2.0 as current. To create and control a stream today, first confirm that your account can access the new Wowza Video UI and v2.0, then follow the current quick start rather than copying an older v1.x request body.
The practical workflow is: obtain a JWT, create a live stream, connect a camera or encoder, start it, and verify its state and playback. This guide explains those steps and where WebRTC and RTMP workflows differ; the exact request fields should always come from the current endpoint reference.
Cloud Name and the Current Wowza Video API
The title phrase remains familiar, but the product naming in current documentation is Wowza Video. Wowza’s API overview identifies v2.0 as the current API and v1.x as legacy. That distinction matters because an older tutorial can still look plausible while using paths, fields or assumptions that do not apply to a current account.
The REST API gives applications a way to create and operate streaming resources over HTTP. Calls exchange JSON, and the API reference describes resources for live streams, transcoders, stream sources and stream targets. A high-level /live_streams workflow is useful when you want the documented setup to cover the associated streaming configuration. A more explicit transcoder workflow gives you a different level of control and should be chosen from the current docs for the task at hand.
If this is your first encounter with the term, our explanation of what a video API does for live streaming can help separate the API itself from the camera, encoder and player that use the resulting stream. The API is not the physical video source: it coordinates software-side setup and lifecycle actions.
Check Access to API v2.0 First
Before writing a request, sign in to your Wowza Video account and check whether the account has moved to the new Wowza Video UI. The v2.0 reference notes that customers who have not migrated to that UI cannot access v2.0. Do not assume an account has access just because an API overview calls v2.0 current.
If v2.0 is unavailable, check Wowza’s current API reference and migration information or ask the account administrator or Wowza support what applies to your account. Avoid “solving” an access problem by silently substituting v1.x sample code: it may refer to a legacy API and its lifecycle or deprecation status needs checking first. If you maintain an existing integration, establish its version and current support status before changing authentication or endpoints.
The API’s version is part of the request URL. The documented pattern is https://api.video.wowza.com/api/[version]/; for v2.0 the reference server is https://api.video.wowza.com/api/v2.0. Keep the selected version explicit in scripts and notes, rather than burying it in a helper whose behaviour is easy to forget. That makes later reviews and migrations easier to reason about.
Obtain and Protect a JWT
Every API request needs a JSON Web Token (JWT) in its authorization header. Wowza’s quick start describes personal tokens for user-linked testing and system tokens for production integrations; system tokens are available to organization owners and are intended for integrations that should not depend on one individual staying with the organisation. Choose a token scope that matches who owns and maintains the integration.
Wowza shows a newly created token only once in the UI. Store it securely when issued. Do not put a real token in a public repository, a screenshot, a shared support ticket or command output that gets retained in logs. If a token is exposed, follow the account’s current token-management guidance rather than assuming that hiding the source file is enough.
For a local shell session, an environment variable keeps the example free of a literal credential:
export WV_JWT='paste-your-token-here'
export WOWZA_API='https://api.video.wowza.com/api/v2.0'
Use the bearer token on each request. POST and PATCH calls also need Content-Type: application/json. A minimal GET request looks like this:
curl --request GET \
--url "$WOWZA_API/live_streams" \
--header "Authorization: Bearer $WV_JWT"
This is a request-shape example, not proof that the token has permission to access every resource. Treat 401 or 403 responses as a prompt to check token validity, account access and permissions. For state checks that must be fresh, consult Wowza’s response-caching documentation: some GET endpoints may return cached responses.
The API uses familiar HTTP method roles: POST creates records, GET retrieves them, PATCH changes selected attributes, PUT performs actions such as starting or stopping, and DELETE removes records. That is a useful mental model, but the endpoint reference is authoritative for each operation and its request body.
Create a Live Stream with the Quick Start
Wowza’s v2.0 quick start demonstrates a WebRTC live-stream workflow using POST /live_streams. The important operational detail is to build the request from the current v2.0 quick-start or OpenAPI reference, not from a JSON body copied from a v1.11 tutorial. Field requirements and accepted values belong to the version you are calling.
A generic request outline shows where the endpoint and headers fit without pretending to be a complete payload:
curl --request POST \
--url "$WOWZA_API/live_streams" \
--header "Authorization: Bearer $WV_JWT" \
--header "Content-Type: application/json" \
--data @live-stream-request.json
Create live-stream-request.json by following the fields currently required in the v2.0 live streams endpoint reference. Do not use the outline above as a substitute for that schema. Check the response for the new resource’s identifier and the connection or playback details relevant to the selected source type. Preserve those details in a secure operational record, with access limited to the people who need them.
The documented quick start is a WebRTC route: create the stream, connect a source, use the Wowza-hosted player page for playback, and operate the stream through API calls. This suits an application or event tool that needs to provision a broadcast as part of its workflow. If you only need to configure a stream manually, a REST client such as Postman can make it easier to inspect the request and response before turning the sequence into code.
Connect a Video Source
A stream resource still needs video and audio from somewhere. In a WebRTC workflow, the camera or other supported source connects through the flow described by the current quick start. A webcam is only one possible physical source; it is not an API requirement, and no particular model should be treated as required or certified. Check the source device’s own documentation and the current Wowza guide for compatibility and setup.
For an RTMP workflow, the source guide describes creating a stream or transcoder using a Wowza stream source, then using the returned connection information in an encoder. Depending on the response, that can include a server or URL, port, application, stream name or key, and relevant credentials. Enter the values into the encoder’s matching fields. OBS is one example: its RTMP server setting uses the server, port and application information, while the stream key field uses the returned stream name/key. Other encoders may label these fields differently, so use the encoder’s documentation rather than guessing.
The source guide says Wowza stream sources do not allow source authentication. Verify that detail against the currently applicable Wowza documentation before relying on it, and account for the resulting security boundary in how you distribute source connection details. Do not expose keys in public overlays, recordings or broadly shared setup notes.
An RTMP source workflow can be configured so Wowza detects the broadcast location, starts when the source begins, and stops after disconnection, as described in the source guide. That changes how much manual lifecycle control your application needs, but it does not remove the need to verify the resulting state and playback. For a 24/7 YouTube channel, source choice and stream control are separate concerns; our guide to preparing OBS playlist files on Linux covers a different, file-looping setup and should not be mistaken for a Wowza API integration.
Start and Stop the Stream Programmatically
Once the source is configured, the v2.0 reference lists a start action at PUT /live_streams/{id}/start. Replace {id} with the identifier returned when the stream was created. The request uses the same bearer authorization header:
curl --request PUT \
--url "$WOWZA_API/live_streams/$LIVE_STREAM_ID/start" \
--header "Authorization: Bearer $WV_JWT"
A successful HTTP response is not the same as confirmed playback. The documented start response can show a state such as starting; this means the start operation has been accepted or is in progress, not that a viewer can already see the programme. Read the response, then check the stream’s current state and verify the playback path using the current source guide.
The reference also lists stop and reset operations. Use the documented stop action when the broadcast should end, and check the resulting state instead of assuming the request completed just because the client did not report an error. Reset is a separate lifecycle operation; use it only when its documented effect fits your recovery or setup process. Do not build a retry loop that repeats start or reset without understanding how the endpoint behaves for a stream already in that state.
A lifecycle script should record which stream identifier it acted on, the API response, and the follow-up state check. If your system schedules events, make its own event record authoritative for intended start and stop times, while treating Wowza’s state and playback checks as evidence of what happened. This makes it easier to distinguish a scheduling mistake from a source that never connected or a start operation that is still pending.
Inspect State and Handle Legacy Examples
After creation or a lifecycle action, inspect the resource details through the current v2.0 endpoint reference. Check the state field and any source or playback details returned for that workflow. For a source-based test, Wowza’s guide describes checking the live-stream state, retrieving a thumbnail URL and opening it in a browser, and checking detected broadcast location where applicable. A thumbnail or player view provides a useful end-to-end check that a response code alone cannot provide.
If the source has disconnected, check whether the documented workflow is meant to stop automatically, then inspect the current state and stop the source when finished. Avoid treating stale cached GET results as definitive where freshness matters; use the caching guidance and repeat a suitable check. A supportable runbook records the API version, resource identifier, action taken, response state and what playback evidence was observed.
Old tutorials may use /api/v1.x/ paths or familiar-looking fields. Label such examples as legacy, check Wowza’s lifecycle and deprecation information, and do not present their bodies as current v2.0 payloads. The name “Wowza Streaming Cloud” in a page title is not itself evidence that its sample is obsolete, but the endpoint version and publication context are reasons to verify it. Where the tutorial and current API reference disagree, follow the current reference for the version your account can access.
The request methods also help you review copied examples: a POST to create a resource is conceptually different from a PUT action to start or stop it. Still, method convention alone cannot validate a legacy example. Confirm the path, request fields, response shape and lifecycle behaviour in the current reference before adapting it to a production script.
Choose the Workflow That Fits the Job
The two source approaches solve related but different problems. WebRTC is the route in Wowza’s documented quick start for connecting a source and using a hosted player page. RTMP suits an encoder-oriented setup in which you configure the encoder with returned connection details. Neither is universally right: select based on your source device, how the broadcast is operated, and the delivery requirements.
| Decision | WebRTC quick-start route | RTMP encoder route |
|---|---|---|
| Source connection | Connect a supported WebRTC source using the current guide | Enter returned server and stream details in an encoder |
| Typical operator | Application or event workflow integrating stream setup | Operator using OBS or another RTMP-capable encoder |
| Playback or delivery | Quick start uses a Wowza-hosted player page | Check the configured stream and delivery path in the source guide |
| Lifecycle emphasis | Create, connect, start, inspect and stop through API | Source can trigger start/stop behaviour, with state and playback checks |
For a straightforward integration, begin with /live_streams and the quick start. If you need explicit transcoder configuration, stream targets or a more tailored delivery setup, study the current lower-level transcoder resources before committing to that design. Keep the number of moving parts proportionate to what your workflow actually needs.
Personal versus system token choice is another operational distinction, not a feature ranking. Personal tokens can suit user-linked testing; system tokens are intended for persistent organisation-owned integrations and are available to organisation owners. Assign responsibility for rotation and storage whichever type you use, and test the integration using the identity and permissions that will operate it.
If your goal is an always-on YouTube loop rather than provisioning a Wowza broadcast through code, that is a different operating problem. For example, compare the practical trade-offs in running a continuous YouTube stream from a Mac mini or cloud service. StreamNeo is relevant when the pain is keeping a prepared video running as a 24/7 YouTube broadcast without leaving your own computer on; it does not replace the Wowza Video API or turn a Wowza workflow into a YouTube integration.
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
Is Wowza Streaming Cloud still the API name?
Current documentation calls the product Wowza Video and identifies v2.0 as the current API, with v1.x marked legacy. Older articles may still use the previous product name, so check the endpoint version and the current reference before adapting their examples.
Why can’t I access the v2.0 API?
The v2.0 reference notes that customers who have not migrated to the new Wowza Video UI cannot access it. Check the account’s UI status and current Wowza guidance before building against another version.
Does a successful start request mean viewers can watch immediately?
Not necessarily. The response can report a state such as starting, so check the stream state and verify playback or a thumbnail using the current source guide.
Can I copy a v1.x request body into a v2.0 call?
Do not assume that fields or lifecycle behaviour carry across versions. Build the request from the v2.0 quick start and endpoint reference, and use legacy material only with its version and status clearly checked.