Authentication
Litmus Unify uses the OAuth2 password grant (unlike Litmus Edge, which uses client credentials):
POST {{uns_url}}/auth/v3/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=password
client_id={{uns_oauth_client_id}}
username={{uns_oauth_username}}
password={{uns_oauth_password}}
Use the returned access_token as Authorization: Bearer <token>. Nearly all endpoints are GraphQL operations posted to a single URL: POST {{uns_url}}/mqtt/gql. The operation is selected by the query body, not the URL path.
API components
UNS
The namespace itself: topic tree hierarchy, namespace rules, and renaming operations.
9 endpoints View in API collectionSecurity
MQTT broker accounts: client IDs, credentials, and per-account publish/subscribe access rules (ACLs).
5 endpoints View in API collectionMQTT
Broker configuration: listeners, TLS, and connection settings.
5 endpoints View in API collectionThe whole product in one place: Litmus Unify in the API collection.
Common multi-step tasks
The most frequent integration task is provisioning a broker account for a new machine or application. The provision a UNS MQTT account guide walks the full five-step chain: create the account, set credentials, attach access rules, and verify connectivity.
Getting data into the namespace
Publishing edge data into Unify is configured on the Litmus Edge side, not here: create an integration instance using the Litmus UNS provider in the Litmus Edge Integration API. The Unify API then governs who may consume that data and how the topic tree is organized.
Reference material
- Environment variables -
uns_urland the OAuth2 password-grant credentials