Read more: Request Formats, Command Reference, Media Formats
To use the API, you will be HTTP posting data to specific URLS on our servers, and handling XML responses. All you need is a programming language that allows you to construct and parse XML (don’t they all?), and to send and receive HTTP. You can get as fancy or as simpe as you want in your code, but we try to make the actual API as simple as possible.
Some of the things you can do with the public API right now:
- transcode a media file at a given URL to one of several different types
- scrape a web page for media, and transcode that media
- receive transcoded media via email or via API callbacks
The Mux Developer Guide is the best source for detailed information on the API.
Getting Access
To get access to our API, you will need to register with us. We do this just so we can tie requests to known email addresses in case of problems. Once you register, you’ll be given a caller ID and a caller KEY. You will provide both of these pieces of information in your API requests, to uniquely identify you are your authorization to use the API.
Sending Requests
You can send an API request (any type of request) to Mux in one of two ways:
- POSTing form-encoded string variables, much like you would a standard HTML web form
- POSTing XML encoded to our schema
There are pros and cons to each method, discussed further in the request formats section of this guide.
With either method, you will be posting to the following base URL:
http(s)://mux.am/api/endpoint/1/basic/
This is the public Mux endpoint, so performance of transcodes may not be indicative of what you can actually achieve using Mux. Please contact us if you would like access to a private, partner endpoint for your development needs.
Providing Credentials
In every one of your API requests, you will need to specify the combination of your caller ID and caller KEY (assigned to you when you register). These should be encoded together according to the general algorithm:
Base64(id:key)
This credential is often referred to as the caller (that’s you) identity. The way you submit this in your API request differs based on whether you are using the XML form or the general form for your requests, discussed in the request formats section.
Handling Responses
All responses from our API will come in HTTP 200 XML payloads. No matter which request form you use, you will always receive XML in response. Your code will need to do some basic parsing, as well as interpret any non-200 error code as an unexpected failure. Under normal operation, commands will return well-defined responses, including Error responses, which contain detailed error information.
Callbacks
In some cases, our API will need to call you back asynchronously. You will always know when this is going to occur, as you will provide Mux with a specific URL to call you back on. We do NOT block network connections for long periods of time while transcoding requests are taking place. In these cases, noted as we describe our API commands, you will receive a request in XML form, sent with a Basic authorization header containing your own credentials. It is your responsibility to validate the credentials provided, and to return an HTTP 200 response with “OK” as the message body. All other response codes and payloads will be treated as an error by our servers and ignored.
Read more: Request Formats, Command Reference, Media Formats

