Overview & Setup

Aura Mixer's Open API lets a trusted local tool on the same PC — a Stream Deck plugin, a Bitfocus Companion module, or any other local automation process — control the mixer. It's the same control surface Aura's own Hotkeys and Automation features use internally, exposed over gRPC so external tools don't need to reverse-engineer anything.

This guide is for developers building an integration. If you just want to turn the feature on, see Settings → Integrations in the app — this page covers what you need to actually connect to it.

What you can build

• A Stream Deck / Companion button that mutes a channel, recalls a scene, or nudges a fader.
• A button whose icon reflects live mixer state (muted/soloed/fader level), via a state stream.
• Anything else that benefits from programmatic control of the mixer from a local process — a macro tool, a game-state-driven automation script, a custom hardware controller.

What it is not (yet)

• Not reachable from another machine or over the network — the listener binds to 127.0.0.1 only. This is a local-tools API, not a remote-control API.
• Not usable from a browser tab. The transport is native gRPC over plain HTTP/2, which browser JavaScript can't speak directly (no raw HTTP/2 frame access from fetch/XHR). A gRPC-Web transport for browser-hosted integrations is planned but not built yet.
• Not a path to real-time audio data. Level meters, LUFS, gain-reduction, and spectrum streams are not exposed (see Limitations below) — this API is for control and discrete state, not for tapping the audio signal.

Architecture, briefly

Aura Mixer runs as two processes: the UI/control process (AuraMixer.exe) and a separate, isolated real-time audio engine (AuraEngine.exe). The Open API listener lives entirely in the UI process — every call you make is relayed from there into the same internal calls the UI itself uses. Your integration never gets a direct path to the audio engine process. This is true for both APIs described in this guide — Actions and Mixer.

Enabling it

In the app: Settings → Integrations (Premium feature).

1. Toggle Enable Open API on. A bearer token is generated automatically the first time.
2. Note the port (default 51477, editable) and copy the bearer token.
3. The status line shows ● listening on 127.0.0.1:<port> once it's actually bound.

Turning the toggle off, or downgrading from Premium, stops the listener immediately.

Getting the .proto files

You need two proto files to generate client stubs in your language of choice:

• mixer.proto — the full per-parameter mixer control surface.
• actions.proto — the higher-level action-catalog surface (recommended starting point).

They're also checked into the Aura Mixer repository under src/Ngs.AuraMixer.Api/Proto/, if you already have repo access — the portal copies above are kept manually in sync with those.

Connecting

The listener speaks plain HTTP/2 (h2c) — cleartext, no TLS. That's a deliberate choice: the socket only ever accepts connections from 127.0.0.1, so there's no network path to eavesdrop on. Most gRPC client libraries default to expecting TLS and need to be told explicitly to allow cleartext HTTP/2. See the worked example for how to do this in Node.js — the equivalent setting exists in every major gRPC client library (look for "insecure credentials" or "h2c"/"h2 cleartext" in your library's docs).

Host:      127.0.0.1
Port:      <from Settings → Integrations, default 51477>
Transport: HTTP/2 cleartext (h2c) — no TLS

Authentication

Every RPC call must carry the bearer token as gRPC metadata:

authorization: Bearer <your-token>

A missing or incorrect token gets you back a UNAUTHENTICATED gRPC status on every call, including streams. There's no separate login/handshake step — the token goes on every single request. Regenerating the token in Settings immediately invalidates the old one.

Two APIs — which one to use

Both are always available once Open API is enabled; they're not alternate modes, just two different surfaces over the same mixer:

• Actions API (actions.proto, ActionsService) — a small, stable catalog of named actions (mute, set fader, recall scene, ...) addressed by target ID + cached display name. Use this by default. It's the same abstraction Aura's own Hotkeys and Automation features are built on, so it won't shift under you as the app evolves internally.
• Mixer API (mixer.proto, 8 services) — the raw per-parameter control surface: every fader, EQ band, gate/compressor parameter, routing send, and more. Use this when you need something the Actions catalog doesn't cover (e.g. individual EQ bands).

Error handling

Standard gRPC status codes apply throughout:

Limitations

A few things are deliberately not exposed, rather than silently faked:

• TransportService.SyncActiveChannels and ChannelsService.UploadHrirPairs — internal bulk state-sync plumbing used by the app itself to keep the audio engine in sync with the UI model. Not a control surface; calling either returns UNIMPLEMENTED.
• MeteringService.StreamLevels / StreamLufs / StreamGr / StreamSpectrum — audio-rate (30–60 Hz) level, loudness, gain-reduction, and spectrum streams. These aren't available through Open API at all right now — there's no internal event source in the App process to relay them from. If you need live mute/solo/fader feedback for a button icon, use ActionsService.StreamState instead, which covers that use case. True audio-rate streaming out to an external tool is a known gap, not a hidden restriction — ask if you need it and it isn't there yet.
• Browser / gRPC-Web transport — not built. This API is for local native processes only, today.

Next

• Actions API reference — start here.
• Mixer API reference — the raw per-parameter surface.
• Worked example (Node.js) — a complete, runnable integration.