AWS Elemental Live’s REST API lets operators automate event setup and runtime input changes on a deployed Elemental Live system. The examples below use documented path patterns, but they are not complete request recipes: confirm the payload, authentication and lifecycle rules in the API guide for your installed release before using them.
This is a guide to Elemental Live, the software and appliance product, not AWS Elemental MediaLive, which has a separate API. If your aim is a continuous YouTube channel rather than operating broadcast equipment, the choices and workflow are different; for example, a pre-recorded YouTube playlist workflow addresses a different operating problem.
Confirm which Elemental product and API you have
AWS Elemental Live is designed to format live video for broadcast television and streaming to internet-connected devices. Its broader product suite includes Elemental Live, Elemental Conductor for cluster management, and optional Elemental Statmux for multi-program transport streams in a Conductor cluster. Those names are related, but they do not mean that every API or endpoint is interchangeable.
The distinction matters most when searching for examples. AWS Elemental MediaLive is a separate AWS service with its own API reference. Do not copy a MediaLive SDK call, endpoint, authentication example or JSON request and assume it works against an Elemental Live appliance. This article does not use MediaLive endpoints.
AWS documents browser, REST and SNMP interfaces for Elemental Live. In its Interfaces for Elemental Live documentation, AWS says: “The REST-based interface supports all features of the web interface as well as automation features.” SNMP is for basic monitoring and control; the browser interface is useful for interactive configuration, while REST is the natural fit for repeatable workflows and integrations. See AWS’s interface documentation for the product-specific explanation.
A practical example of the distinction: an operator can use the web interface to configure an event manually, then use a deployment-matched REST guide to automate a supported change or inspect its state. SNMP may help with basic monitoring, but it should not be treated as a substitute for the REST event and playlist operations discussed here. For a separate always-on streaming workflow based on a computer, consider how a UPS affects a 24/7 YouTube setup; that does not make it equivalent to an Elemental deployment.
Prepare access to a deployed system
These calls target a deployed Elemental Live system, represented in the examples as <Live IP Address>. Before writing automation, establish which appliance or system the address identifies, which release it runs, and how your organisation expects access to be managed. Do not treat the placeholder as a public AWS endpoint. The example paths below are rooted at the Elemental Live system.
Find the API guide associated with that deployment before deciding the exact request format. AWS says the Elemental Live API guide is available from the product’s Support tab in the appliance web interface. That on-system guide is a useful version-matched reference because an example found elsewhere may reflect another release. AWS’s Elemental Live documentation landing page provides product documentation, but the appliance’s guide should inform implementation details for your installation.
Current user documentation covers Elemental Live from version 2.17 and Conductor from version 3.17 onward, according to AWS’s documentation page. That statement describes the scope of those current documents, not a guarantee that a particular endpoint or field exists in every deployment. Check the version running at your site and the matching API material. Do not assume that a newer guide’s payload schema applies unchanged to an older system.
Access preparation also includes operational decisions that are not settled by a URL. Agree who may make changes, where credentials or other access material belong, which system is a safe place to validate a workflow, and how a change is approved. The research material here does not establish a particular authentication method, so do not infer one from these endpoint examples. Follow your installed guide and your organisation’s security policy for credentials and access controls.
If you are accustomed to scripts that send a playlist directly to YouTube, keep that mental model separate. Elemental Live’s API operates on its own events and inputs. A recordings-based continuous YouTube playlist is an example of a creator-oriented workflow, not a description of Elemental Live’s API.
Understand the REST workflow
Think of the REST API in two phases. Event creation or modification establishes the event configuration; runtime playlist commands then manage inputs while an event is operating. The event examples documented by AWS use HTTP POST to create an event at /live_events and PUT to modify one at /live_events/<live event id>. The request body is XML structured under a <live_event> element.
A deliberately small shape-only illustration is:
POST http://<Live IP Address>/live_events
Content-Type: application/xml
<live_event>
<.-- fields must come from the guide for this release -->
</live_event>
This shows the method, path and broad XML structure, not a complete valid event configuration. Do not send it as-is: the comments are explanatory, and the required fields, optional fields and request headers must be confirmed in the matching guide. AWS’s API event-field example demonstrates setting an event name and configuring a motion image inserter, including enable_rest. That feature-specific example is not a full schema for every event.
For an existing event, the documented modification pattern is:
PUT http://<Live IP Address>/live_events/<live event id>
Content-Type: application/xml
<live_event>
<.-- update fields documented for this operation and release -->
</live_event>
The URL’s event identifier must refer to the event you intend to change. The sample is not evidence that a particular field can be changed while an event is running, nor that any arbitrary partial XML body is accepted. Confirm both the operation’s constraints and the request format in the API guide.
The workflow becomes more stateful when changing a live event’s inputs. A dynamic playlist is not simply a list to overwrite without regard to what is on air. AWS documents operations to append inputs, replace non-active playlist inputs while retaining the active one, prepare or activate an input, and inspect event status. Some commands require a running event, and the modify and delete patterns apply to a non-active input. These lifecycle details shape the automation more than the HTTP verb alone.
Example: inspect event and channel state
Before issuing a change, retrieve the event and its inputs using the documented pattern GET /live_events/<event ID>. For an operator, this is a useful starting point: it connects the identifier used by a scheduled task to the event configuration the system reports. Treat the returned representation as information to inspect according to the guide, not as a payload to edit and send back without checking the API’s rules.
A separate documented path pattern retrieves event status: GET /live_events/<event ID>status. AWS’s command list says this reports status including input stage and state. The unusual-looking suffix is shown as a path pattern from the documentation; verify its exact spelling and expected response against the installed API guide rather than “correcting” it based on assumptions about REST naming.
A simple operational sequence is to query the event, record the event ID and relevant input IDs, then query status before a scheduled change. After the operation, query status again and compare the reported stage and state with the outcome expected by the workflow. This is an editorial synthesis of AWS’s documented commands, not a tested procedure or a guarantee about a particular response body.
Use explicit identifiers in automation rather than relying on display names alone. A script should make it clear which event and input it is inspecting, and its log should retain enough context for an operator to diagnose an unexpected result. The exact response fields available and their meanings belong to the installed guide. Avoid building a parser around assumed fields copied from a different release.
For a creator deciding between infrastructure-based approaches, a headless Linux PC playlist stream is a different system with different checks. Here the relevant status comes from the Elemental Live event API, not a YouTube playlist runner.
Example: automate a channel operation
Suppose a running event normally takes a live source, and an operator needs to insert a file-based segment before returning to the live source. AWS’s sample implementations describe patterns such as interrupting a live input with ad content and returning, switching to another live source, using looped file content as an emergency fallback, or sequencing movie and ad segments before returning to a live feed. The exact input configuration and timing depend on the deployment and its matching API guide.
The dynamic playlist command patterns include:
| Task | Documented path pattern | Constraint to check |
|---|---|---|
| Append inputs to a running event’s dynamic playlist | POST /live_events/<event ID>/inputs |
The event must be running; confirm the input body schema |
| Replace non-active playlist inputs while retaining the active input | POST /live_events/<event ID>/playlist |
Confirm which inputs are non-active and what replacement body is required |
| Modify a playlist input | PUT /live_events/<event ID>/inputs/<input ID> |
The target input must be non-active |
| Delete a playlist input | DELETE /live_events/<event ID>/inputs/<input ID> |
The target input must be non-active |
| Prepare an input | POST /live_events/<event ID>/prepare_input |
The operation may optionally schedule activation; validate its parameters |
| Activate an input | POST /live_events/<event ID>/activate_input |
Activation may be immediate or at a specified time; validate timing fields |
These are path patterns, not complete requests. In particular, this table does not define authentication, headers, XML structure, query parameters, timestamps or every state prerequisite. AWS’s dynamic playlist command list is the source to consult for operation details and lifecycle constraints.
An automation plan for the live-to-file-to-live case can be expressed without guessing a payload. First, establish the event and its primary live input. Next, construct the intended playlist inputs using the release-specific guide. If the workflow calls for preparation, prepare the next non-active input; activate it immediately or at the intended time using the documented operation and fields. Finally, retrieve status and check whether the event reports the expected input stage and state. This sequence is an editorial synthesis of documented commands and examples, not a tested procedure.
A similar pattern can support a planned switch to another live source or a temporary fallback to looped file content. The important control is the transition: identify which input is active, leave it intact where the replacement operation requires that, and make the intended next input ready before activating it. If a return to the original source is required, treat that as another explicit transition in the schedule rather than assuming a playlist will restore it automatically.
Handle responses, errors and operational checks
A successful HTTP exchange is not the same as the intended change reaching the desired event state. The API guide’s operation-specific response information should determine how your client recognises completion, rejection or an invalid request. The material referenced here does not provide a universal response schema or authentication recipe, so this article does not invent one. Record the HTTP result and any response details the guide identifies as meaningful.
When a call fails or the event does not appear to change, check the basics in a deliberate order: confirm that the request reached the intended Elemental Live address; confirm that the event and input identifiers belong to that system; check the operation’s running-event or non-active-input constraint; and compare the method, path and body with the installed guide. A likely problem may be a lifecycle mismatch rather than a malformed URL. Do not retry a state-changing request blindly if you do not know whether the first attempt took effect.
Build operational checks around observed state. Before a scheduled transition, retrieve the event and status; after it, retrieve status again and compare it with the expected stage and input state. If the result is ambiguous, pause further changes and have an operator inspect the event through the supported interface. Keep logs useful to the next person on duty: include the event identifier, intended operation and observed outcome without exposing credentials.
Do not rely on an example copied from a different Elemental Live release just because the path looks familiar. Payload details, supported fields, and operational constraints need release-specific confirmation. Likewise, do not map a MediaLive example into this workflow to fill a gap; its API belongs to a different product. The safest automation is bounded: make one documented change, check state, and stop if the observed result differs from what the runbook expects.
Where Conductor and optional Statmux fit
Elemental Live is part of a suite that can include Elemental Conductor for cluster management and optional Elemental Statmux for multi-program transport streams in a Conductor cluster. That context matters if the deployed system is managed as a cluster rather than as a single appliance. Do not assume that an event-level Elemental Live request is also a Conductor management operation, or that Statmux introduces no additional considerations.
Keep the API boundary clear in your automation design. Use the Elemental Live guide for the Live event and dynamic playlist operations described here. Use the documentation matching the deployed Conductor release when a task concerns cluster management, and consult the appropriate Statmux material where that component is in use. The sources cited here establish the suite relationship, but they do not provide enough detail to specify Conductor or Statmux endpoint examples.
Version checks are relevant across the suite: AWS’s current user-document scope begins at Elemental Live 2.17 and Conductor 3.17. Confirm the release actually deployed and the reference intended for it before adapting an example. The goal is not to force every task into REST; browser interaction may remain appropriate for manual setup, while SNMP is described for basic monitoring and control. Choose the interface according to the operation and supported capability.
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 this the same API as AWS Elemental MediaLive?
No. Elemental Live is the deployed software or appliance product covered here; MediaLive is a separate AWS service with a separate API reference. Use documentation for the product actually deployed, and do not substitute MediaLive endpoints or request examples.
Can I copy the XML snippets and run them as-is?
No. They show only the documented method, path pattern and broad <live_event> body structure. The required fields, headers, authentication and exact schema must come from the API guide for your installed release.
Does every playlist operation work on any event state?
No. AWS’s command documentation includes lifecycle constraints: some operations require a running event, and modifying or deleting an input applies to a non-active playlist input. Check the specific command’s conditions and verify event status before automating a transition.
Where do I find the matching API guide?
AWS says the Elemental Live API guide is available from the Support tab in the appliance web interface. Use that guide to confirm your release’s request details and operation constraints before adapting any example.