Every amplifier exposes a hierarchical JSON REST API used by Maxx Control itself and by third-party systems. Prefer this API for single-device integration. For project-level multi-amp control, use the Maxx Remote HTTP API instead.
Base URL and transport
Item
Value
Scheme / port
http:// on port 80
Base path
/rest-api
Example
http://${IP}/rest-api/settings/channel/1/dsp/mute
Methods you will use most: GET (read), PUT (write / partial update), OPTIONS (allowed ranges and constraints), plus POST / DELETE on a few resources (for example EQ bands).
Authentication
Write operations that change settings require an API key in the HTTP header:
Header
Default value
token
f4005bf8507999192162d989d5a60823
Defined in OpenAPI as ApiKeyAuth (token in header). GET and most OPTIONS calls do not require the token. Most PUT (and many DELETE) calls do — check the on-device OpenAPI for each path; a few DELETE endpoints are unauthenticated in the schema.
The tree is organized under /settings (configuration), /status (live state), /info, /preset, and helpers such as /speakerpreset. Channel resources nest DSP blocks (volume, mute, EQ, FIR, limiters, …); device resources cover master mute/volume, Dante, network, and more.
You can:
PUT a deep leaf, e.g. …/settings/channel/1/dsp/mute
PUT a parent with a partial JSON object, e.g. …/settings/channel with an array of channel objects
PUT…/settings with a larger tree when you need a wide update in one call
Partial updates are the normal pattern: send only the fields you want to change.
OPTIONS = parameter constraints
OPTIONS on a resource returns the allowed parameter space for that property (min / max / step / unit, enums, string lengths, and similar). Use it when building UIs or validating values before PUT — especially for volume, delay, limiters, and names.
Exact response fields vary by resource; see the on-device OpenAPI schemas (for example NumberOptions).
Full OpenAPI (source of truth)
This site documents common integrator patterns. The complete, firmware-matching schema is on the device:
Open Maxx Control → OVERVIEW
Click REST API DOC (lower right)
That opens the Swagger UI for maxx_rest_api.html (generated from the device OpenAPI). Always trust the on-device docs for path lists and schemas for your firmware version.
Third-party plugins (Q-SYS, Loxone, …) use this same API against one amplifier each — see Third-party plugins.
1 - Maxx Control REST: Set channel names
Maxx Control REST: get and set channel names for zones, UI labels, and home-automation integrations.
Use the Maxx Control REST API to get and set channel names so zones and automation UIs stay readable. Names can contain alphanumeric characters, spaces, and special characters.
Tip: Use descriptive channel names to make your system easier to manage, especially when integrating with home automation systems or control interfaces.
2 - Maxx Control REST: Control device mute and volume
Maxx Control REST: set device master mute, master volume, and startup mute for one Innosonix amplifier.
Use the Maxx Control REST API to set device-level master mute, master volume, and startup mute on one amplifier. These controls affect all channels globally — useful for emergency mute, master volume, and safe startup behavior.
Device Mute
The device mute acts as a master mute that affects all channels, regardless of individual channel mute settings.
Use Case: Enable startup mute to prevent audio from playing immediately after power restoration, giving you time to verify system status before audio begins.
Complete Device Control Example
Here’s an example that combines multiple device-level controls:
# Set device to start mutedcurl -X 'PUT' http://${IP}/rest-api/settings/device/dsp/startupmute \
-H 'Content-Type: application/json'\
-H 'token: f4005bf8507999192162d989d5a60823'\
-d '{"value": true}'# Set master volume to a safe levelcurl -X 'PUT' http://${IP}/rest-api/settings/device/dsp/volume \
-H 'Content-Type: application/json'\
-H 'token: f4005bf8507999192162d989d5a60823'\
-d '{"value": -10.0}'# Unmute device when readycurl -X 'PUT' http://${IP}/rest-api/settings/device/dsp/mute \
-H 'Content-Type: application/json'\
-H 'token: f4005bf8507999192162d989d5a60823'\
-d '{"value": false}'
3 - Device Information
Examples for retrieving device information
Getting Device Information
The device information endpoint provides details about your amplifier model, available channels, installed options, and hardware features.
Get Device Information
Retrieve all device information with a simple GET request:
model_name: The amplifier model (e.g., MA32D, MA32LP, MA24D2)
channel: Number of available channels (16-32)
options: Array of installed options:
IF1, IF2, IF3: Interface options
D1, D2, D3: Dante options
M1: Additional options
psu_fan: Whether PSU fan is installed
housing_fan: Whether housing fan is installed
This information is useful for:
Verifying device capabilities before making API calls
Determining available channel count
Checking installed hardware options
Building device-specific automation logic
Status snapshot
Read calls do not need the token.
GET /status returns the full status tree (channels, device, interfaces, save state, syslog summary).
curl "http://${IP}/rest-api/status"
Health-oriented errors
GET /status/error aggregates channel and device errors with severity and status_flags (error / warning / ok).
curl "http://${IP}/rest-api/status/error"
Narrower reads are available, for example GET /status/device or GET /status/channel/{channel_id} — see on-device OpenAPI.
4 - Maxx Control REST: Enable or disable EQ
Maxx Control REST: enable or disable channel EQ (eqenable) with single-channel and multi-channel PUT examples.
Use the Maxx Control REST API to enable or disable channel EQ (eqenable) — bypass the whole equalizer for testing or mode changes while keeping filter settings intact.
Enable EQ for Multiple Channels
Enable the equalizer for multiple channels in a single request:
Note: When EQ is disabled, all equalizer settings (filters, gains, etc.) are bypassed, but the settings themselves are preserved. Re-enabling EQ will restore the previous equalizer configuration.
5 - Mute Control
Examples for controlling channel and device mute states
Channel Mute Control
Mute control allows you to silence individual channels or the entire device.
Note: Device volume acts as a master volume control affecting all channels. Individual channel volumes are relative to this device volume setting.
7 - AES67 / SDP subscribe
Maxx Control REST: subscribe a channel input to an AES67 / SDP stream (source_id 25) by PUTting sdp_text or rtp_flow.
Subscribe an amplifier channel DSP patch to an external AES67 / SDP audio source. This is the same path Maxx Control’s channel-input UI uses when you paste SDP or pick a discovered AES67 flow.
When to use
Use this when a third-party sender (PipeWire, another AES67 device, etc.) publishes an SDP session and you want a MAXX channel to receive that multicast/unicast RTP stream as its input source AES67 STREAM (source_id25).
Do not confuse this with:
API concept
source_id
Typical fields
AES67 STREAM
25
sdp_text (PUT) or rtp_flow
DANTE STREAM
23
label / channel_name / device_name
Device Dante AES67 mode
n/a
PUT /settings/device/dante/aes67 with {"value": true|false}
Dante AES67 enable is a separate device setting (Brooklyn AES67 mode). AES67 STREAM patches use the channel patch API below.
Prerequisites
Amplifier reachable at http://${IP}/rest-api/… (see REST API overview).
Firmware that exposes AES67 STREAM as an input source. Confirm with:
Look for source_id: 25 / "AES67 STREAM" in the source list.
A complete SDP the device can parse (see SDP requirements below).
Write calls need the API key header token (default documented in the overview).
API path and method
Item
Value
Method
PUT (writes require token)
Path
/settings/channel/{channel_id}/dsp/patch
Body
JSON array of patch objects (SettingsPatches)
Read back
GET same path (or …/patch/{patch_id})
Constraints
OPTIONS on the same path
There is no PUT on /settings/channel/{channel_id}/dsp/patch/{patch_id} — only GET for a single patch. Writes always go to the collection path with one or more objects in the array.
Payload fields (AES67 STREAM)
Field
Role
patch_id
Required. Patch slot on the channel (1…16).
source_id
25 for AES67 STREAM.
channel
Slot within the RTP stream (1…N from SDP a=rtpmap channel count), not the Brooklyn RX channel.
sdp_text
PUT-only, at patch root. Full SDP string; server parses into flow params. Max length 512. Not returned on GET.
rtp_flow
Alternative to sdp_text: structured fields (connection_ip, rtp_port, sample_rate, encoding, channels, session_name, clock_offset, session_id, source_address). Returned on GET after a successful subscribe.
gain
Optional patch gain (dB).
mute
Optional patch mute.
stream_channel
GET-only Brooklyn RX channel assigned after placement (0 until placed). Do not send on PUT.
Rules from firmware / OpenAPI:
Put sdp_text on the patch object root. Nested rtp_flow.sdp_text is rejected.
Do not send sdp_text and structured rtp_flow params together.
Prefer one approach: paste SDP or fill rtp_flow.
SDP requirements
Server-side parse (same as Maxx Control paste) requires a parseable AES67 SDP with:
PCM encoding L16 or L24 (encoding 16 or 24)
o= session id and origin IPv4 (source address)
a=mediaclk:direct=… (or equivalent) so clock offset is present
OpenAPI maxLength for sdp_text is 512 characters. Trim optional SDP lines if you hit the limit.
Step-by-step: PUT with sdp_text
Choose amp channel (channel_id) and patch (patch_id, often 1).
Choose stream slot (channel: 1 = first channel in the SDP, 2 = second, …).
PUT an array with one AES67 patch object including sdp_text.
GET the patch back — expect source_id 25 and populated rtp_flow (not sdp_text).
Optionally check patch status and persist with /settings/save.
This session is 2 channels at 48 kHz / L24. Use "channel": 1 for L and "channel": 2 for R on two amp channels (or two patches) if needed.
JSON shape
[{"patch_id":1,"source_id":25,"channel":1,"gain":0.0,"sdp_text":"v=0\no=root 1 3991817848 IN IP4 172.149.4.123\ns=stream1\n…"}]
Newlines in SDP must be encoded inside the JSON string (\n). Do not put raw multi-line SDP inside a single-quoted -d '…' shell string unless you build JSON with a tool.
Exact field meaning matches OpenAPI schema SettingsPatch / rtp_flow.
Verify
# Settings: parsed flow (sdp_text is write-only — not echoed)curl "http://${IP}/rest-api/settings/channel/1/dsp/patch/1"# Patch healthcurl "http://${IP}/rest-api/status/channel/1/dsp/patch/1"# Optional: SAP-discovered sessions (cache; may include sdp_text)curl "http://${IP}/rest-api/info/aes67"# Optional: Dante interface flows (interface_id from GET /status/interface/interfaces)curl "http://${IP}/rest-api/status/interface/interfaces/4"
Persist runtime settings if needed:
curl -X PUT "http://${IP}/rest-api/settings/save"\
-H "token: ${TOKEN}"
Related discovery endpoints
Path
Method
Purpose
/info/aes67
GET
SAP-discovered AES67 flows (cache)
/info/aes67/refresh
PUT
Clear SAP cache (listening continues)
/settings/device/dante/aes67
GET/PUT
Device Dante AES67 enable ({"value": bool})
Source of truth
Path lists and schemas follow the on-device OpenAPI (Maxx Control → OVERVIEW → REST API DOC). Firmware versions can add fields; always confirm SettingsPatch on the live device. See also the REST API overview and input patch recipes.
8 - Maxx Control REST: Switch input patches
Maxx Control REST: switch amplifier channel input patches (Dante and other sources) with bulk or per-channel PUT examples.
AES67 / SDP
To subscribe a channel to an AES67 / SDP stream (source_id 25), see AES67 / SDP subscribe.
Use the Maxx Control REST API to switch channel input patches (for example Dante slots) with a bulk PUT or per-channel calls. When switching between inputs, there are multiple approaches:
Example Configuration for CH1, CH2, CH4, CH7, switch between Dante Input 1-4 and Dante Input 21-24
HTTP Put a full json object containing all affected Channels into the http://${IP}/rest-api/settings/channel/ path
Advantage: Using the bulk endpoint /settings/channel/ allows you to patch multiple channels in a single HTTP call, which is more efficient than making individual calls for each channel. This reduces network overhead and ensures all channels are updated atomically.
To determine the source_id of the desired Interfaces, perform an HTTP OPTION call to http://${IP}/rest-api/settings/channel/1/dsp/patch' to get a list of available interfaces.
Alternatively, you can patch each channel individually by making separate HTTP PUT calls to each channel’s endpoint: http://${IP}/rest-api/settings/channel/{channel_id}/
This approach allows you to update channels one at a time, which can be useful when you need to patch channels conditionally or handle errors per channel.
Assuming we’ve already patched our desired Inputs for each channel on Slot 1 and 2
When inputs are already patched, you can toggle the mute state between different patch slots (e.g., Slot 1 and Slot 2) by only updating the mute flag in the patch object. This is more efficient than repatching the entire input configuration.
HTTP Put a JSON object containing all affected Channels into the http://${IP}/rest-api/settings/channel/ path, specifying only the patch_id and mute flag for each patch slot.
You can also toggle mute on individual channels by making separate HTTP PUT calls to each channel’s endpoint: http://${IP}/rest-api/settings/channel/{channel_id}/
Use "value": false to disable. Multi-channel updates can go through PUT /settings/channel with ampenable on each object.
10 - Save / persist
Persist runtime REST changes with /settings/save and check save status.
Runtime changes are held until they are saved. Trigger a manual save with:
PUT /settings/save (token required; no JSON body)
curl -X PUT "http://${IP}/rest-api/settings/save"\
-H "token: f4005bf8507999192162d989d5a60823"
Check save / autosave state with GET /status/save.
Note
The device may also autosave. Integrators that change many parameters in a burst should still call /settings/save when a persistent result is required (power cycle / reboot).