REST API vs Java API: How To Use The Wowza REST API for Smarter Streaming Workflows
Wowza Streaming Engine ships with two APIs, which serve fundamentally different purposes. The REST API handles configuration and control, including starting streams, managing recordings, provisioning cameras, and automating the operational side of your streaming infrastructure. The Java API handles extensibility, and is for building custom server-side modules that add entirely new capabilities to the streaming pipeline itself.
Understanding which API to reach for (and when to combine them) is the difference between a manual, UI-dependent workflow and a fully programmable streaming platform. This post breaks down what the Wowza Streaming REST API does, what the Java API does, when to use which, and how organizations are putting them to work in production.

What Wowza’s REST API Does
The Wowza Streaming Engine REST API exposes the same functionality available in Wowza Streaming Engine Manager but as HTTP endpoints you can call from any language, script, or application. Rather than clicking through a UI to configure streams and manage server settings, you do it programmatically through REST API calls.
The REST API automates stream lifecycle management, letting you start, stop, and reset live streams and recordings on demand. It also allows you to create and modify applications, set up stream files to pull from new camera sources, and configure transcoder templates for adaptive bitrate delivery. For distribution, you can use the REST API to create and manage stream targets for push publishing to CDNs, social platforms like YouTube and Facebook Live, or services like Akamai. Automate server log retrieval, diagnostics, and real-time performance statistics, and set up webhooks to get notified when streaming events occur. Finally, it lets you manage user authentication and HTTP response headers for access control.
The REST API also comes with Swagger/OpenAPI documentation and Postman collections, which means you can explore and test endpoints before writing a line of integration code. If you are building an application where Wowza Streaming Engine sits at the core, and you need to manage it from your own software, the REST API is how you do it. It’s the control plane for your streaming infrastructure.
What Wowza’s Java API Does
Wowza’s Java API operates at a completely different layer than the REST API. Instead of managing Wowza Streaming Engine from the outside, the Java API lets you extend what it can do from the inside.
Server-side modules are Java classes that load when a Wowza Streaming Engine application starts. They plug directly into the streaming pipeline and can intercept, process, and act on media as it flows through the system. The REST API controls existing features, whereas the Java API creates new ones.
Java modules are configured per-application and load dynamically. You write a Java class, compile it into a .jar file, drop it into Wowza Streaming Engine’s lib directory, and reference it in your application configuration. Wowza provides two development paths:
- The Wowza IDE, an Eclipse add-on for traditional Java development
- The Wowza Plugin Builder, a Gradle and Docker Compose setup for teams that prefer modern, containerized workflows
If you want to add capabilities that don’t exist out of the box, the Java API is how you build them. Integrate Azure AI Speech Services or OpenAI Whisper for real-time speech-to-text captioning. Insert ad markers for server-side ad insertion delivery. Mix audio and video from multiple live sources into a single output. Duplicate streams across application instances. Collect per-stream performance metrics and forward them to Google Analytics. Handle custom protocols for specialized camera and device integrations.
REST API vs Java: Key Differences
The simplest way to think about the two APIs is through two questions. If you’re asking “how do I automate managing my streams?” the answer is the REST API. If you’re asking “how do I make my streams do something new?” the answer is the Java API.
| REST API | Java API | |
| Primary Purpose | Configuration and control | Extensibility and custom logic |
| What It Does | Automates operational tasks: start/stop streams, manage configs, provision cameras | Adds new capabilities to the streaming pipeline: custom processing, integrations, workflows |
| Interface | HTTP/REST endpoints callable from any language | Java classes compiled into .jar modules and uses java interfaces |
| Best For | Building management applications, automating deployment, replacing manual UI tasks | Building custom stream processing, integrating third-party systems, adding downstream workflows |
| Technical Skills Required | Any language that can make HTTP calls | Java development |
| Deployment Impact | No server restart needed | Requires application or server restart when modules change |
Wowza’s REST API In Action
The value of the REST API compounds at scale. When you’re managing a dozens, hundreds, or thousands of video streams, the REST API provides much-needed automation. Build a management layer on top of the REST API, and your streaming infrastructure becomes as programmable and scalable as the rest of your stack.
How MDOT Manages 1,300 Traffic Cameras Across Mississippi
Mississippi DOT (MDOT) operates one of the larger statewide traffic camera networks in the country, with roughly 1,300 RTSP cameras in their public-facing network. Their Enterprise Systems Architect, Clint Johnson, and his team built a custom management platform called Camera Manager that serves as the central system of record for every camera in MDOT’s inventory.
Camera Manager leans heavily on the Wowza Streaming Engine REST API to automate what used to be manual work. Adding a new camera, assigning it to a regional Wowza server, provisioning the stream, and migrating cameras between servers when hardware fails all happens through API calls. Nobody ever touches a configuration file.
MDOT also uses the REST API to run automated health checks against the full camera inventory every two hours. They test response times, connectivity, and stream health across the entire statewide network. That kind of systematic, API-driven monitoring simply isn’t possible through a manual UI workflow, especially with a smaller operations team.
Because MDOT had already built a fully programmable, API-driven infrastructure, they were able to layer AI-powered video intelligence on top of it. The system pulls still image thumbnails from every active camera via the Wowza Transcoder, sends them to a vision model, and scans all 1,300 cameras every minute, around the clock. Compared to the 16-minute manual cycle their operators were limited to before, the value of an API-first architecture speaks for itself.
Event-Driven Stream Orchestration
Consider a facility monitoring operation that needs to spin up surveillance streams during business hours and shut them down overnight to conserve bandwidth. Rather than having someone log in twice a day, the REST API integrates with a scheduler to handle the lifecycle automatically. Streams come up in the morning, go down at night, and bandwidth isn’t consumed during off hours. The same pattern applies to any scenario where stream lifecycle needs to respond to external events like shift changes, scheduled broadcasts, and demand-based scaling.
Multi-Platform Distribution
When a broadcaster needs to push a live stream to streaming apps and a CDN simultaneously, the REST API handles stream target creation and management. The REST API also handles configuration for each destination. This is especially valuable for recurring broadcasts where the same distribution pattern needs to be set up reliably every time.
Wowza’s Java API In Action
Where the REST API automates operations, the Java API creates entirely new capabilities within the streaming pipeline.
Real-Time AI-Powered Captioning
A media company needs live captions on their streams for accessibility compliance. Rather than routing audio through an external captioning service and trying to synchronize the results, a Java module integrates speech-to-text directly into the streaming pipeline. The Java API intercepts the audio track, sends it to Azure AI Speech Services or OpenAI Whisper, receives the transcription, and injects caption data back into the stream. The result is lower latency, tighter synchronization, and one less external dependency in the architecture.
Custom Protocol Integration
Organizations with IP cameras that use specialized protocols like ONVIF need a bridge between their camera infrastructure and the streaming platform. A custom Java API module can handle ONVIF discovery and control directly within Wowza Streaming Engine, connecting the camera network to the streaming infrastructure without third-party middleware. This kind of protocol-level integration is exactly what the Java API is designed for.
Downstream Analytics and Workflow Automation
A streaming platform needs real-time visibility into how streams are performing, or needs to trigger downstream workflows based on stream events (like transcoding jobs, notifications, and content archival). Java modules hook into the streaming lifecycle at the application level, capturing events and metrics as they happen and forwarding them to external systems like Google Analytics, custom dashboards, or workflow orchestration tools. This turns Wowza Streaming Engine from a standalone media server into an integrated component of a larger data pipeline.
Live Stream Mixing and Manipulation
A production team needs to combine audio and video from multiple live sources into a single output for multi-camera live events where switching and mixing need to happen server-side. A Java module handles media manipulation directly within the engine. The Java API avoids the round-trip latency and complexity of external mixing infrastructure. The output is a single, mixed stream ready for delivery.
Using The REST API With The Java API
The REST API and Java API are complementary. Operations teams manage camera fleets through REST API calls. Engineering teams build intelligence into video pipelines through the Java API. A combined workflow might look like this:
- The REST API programmatically provisions a new camera stream and assigns it to the appropriate regional server
- The REST API automatically starts the feed
- Meanwhile, a Java API module automatically processes every frame through a computer vision model, detects anomalies, and forwards alerts to a monitoring dashboard.
This makes Wowza Streaming Engine a programmable platform rather than just a streaming server. The REST API makes it operationally scalable. The Java API makes it functionally extensible. Together, they let you build streaming infrastructure that adapts to your architecture instead of constraining it.
Getting Started With Wowza Streaming Engine’s REST API and Java API
For the REST API, the Wowza Streaming Engine REST API documentation includes full endpoint references, Swagger/OpenAPI specs, and Postman collections you can use to explore the API interactively. For the Java API, the Java API overview covers the module architecture. The module examples library provides working code for common use cases like captioning, stream duplication, and analytics integration. If you prefer a modern development workflow, the Wowza Plugin Builder offers a Gradle and Docker Compose environment for building and testing modules locally.
Whether you’re automating stream management or building custom pipeline logic, Wowza provides the tooling to get started quickly. Get in touch today for a custom demo.
REST API vs Java API FAQs:
What is the difference between a REST API and a Java API?
A REST API uses standard HTTP requests (GET, POST, PUT, DELETE) to interact with a system remotely. Any programming language that can make HTTP calls can use a REST API. A Java API, by contrast, is a set of Java classes and interfaces that you use to write code that runs directly inside the application.
In Wowza Streaming Engine, the REST API manages the server from the outside (configuring streams, starting recordings, provisioning applications) while the Java API extends the server from the inside by adding custom modules that process media within the streaming pipeline itself.
Is a REST API better than a Java API?
Neither is inherently better, they solve different problems. The REST API is the right choice when you need to automate operational tasks like starting and stopping streams, managing configurations, or building a custom management dashboard. The Java API is the right choice when you need to add new capabilities to the streaming pipeline, such as real-time captioning, custom protocol support, or downstream workflow triggers. The best architectures often use the REST API for fleet management and the Java API for pipeline-level logic.
Can a REST API and Java API be used together?
Yes, and they’re designed to be complementary. A common pattern in Wowza Streaming Engine is to use the REST API to programmatically provision and control streams while Java modules running on those same applications handle custom processing. For example, the REST API might spin up a camera feed and assign it to a server, while a Java module on that application automatically runs each frame through a computer vision model. The operations team works through the REST API, while the engineering team builds intelligence through Java modules.
Is REST API language-specific?
No. One of the core advantages of a REST API is that it’s language-agnostic. Any language or tool that can make HTTP requests (Python, JavaScript, Go, cURL, Postman, or even a simple shell script) can interact with a REST API. The Wowza Streaming Engine REST API includes Swagger/OpenAPI documentation and Postman collections to make it easy to explore and test endpoints regardless of your preferred language or development environment.
When should I use a Java API instead of a REST API?
Use the Java API when you need to do something that the REST API can’t. Specifically, if you need to add custom logic that runs inside the streaming pipeline, use the Java API. If you need to intercept and process media in real time (like speech-to-text captioning), integrate with specialized protocols (like ONVIF camera discovery), trigger downstream workflows based on stream events, or manipulate media (like mixing multiple live sources), those are Java API use cases. If you’re managing existing functionality (starting streams, changing configurations, monitoring health) that’s handled by the REST API.
Are REST APIs slower than Java APIs?
They operate at different layers, so a direct speed comparison isn’t quite the right framing. You wouldn’t use the REST API for real-time frame-by-frame media processing (that’s what Java modules are for), and you wouldn’t write a Java module just to start and stop streams (that’s what the REST API is for). Each is optimized for its intended use case. REST API calls involve an HTTP request-response cycle over the network, which introduces some latency compared to code running directly inside the Java Virtual Machine. However, this difference is negligible for the kinds of tasks each API is designed for.
Do REST APIs require a server restart?
No. REST API calls take effect immediately without requiring a server or application restart. This is one of the practical advantages of using the REST API for operational tasks. You can start and stop streams, modify configurations, and manage stream targets on a live server without any downtime. Java API modules, by contrast, do require an application or server restart when you add or modify them, since they load as classes when the application starts.
Can Java APIs be accessed remotely?
Not directly in the same way a REST API can. Java API modules run as server-side code inside the Wowza Streaming Engine process on the server itself. You don’t call them over HTTP the way you would a REST endpoint. However, Java modules can expose their own HTTP endpoints or interact with external systems, and you can trigger behavior in Java modules indirectly through REST API actions. For example, starting a stream via the REST API will cause any Java modules configured on that application to begin executing their logic on the incoming media.
