nexalwarenexalwaredocs
API ReferenceDevices

Re-show a device's existing MQTT credentials

Dashboard-only

This mirrors what a human does from the Nexalware web app - it's not meant to be automated by a third-party integration, even though a session token from Log in can technically call it. If you're building an integration that controls devices, use an API key instead: have an Owner/Admin grant it access to a device (a DeviceGrant), and use the Device Control endpoints.
POST
/api/v1/devices/{deviceId}/credentials/reveal

Step-up protected - requires re-confirming your account password. Every call is written to the device's audit log.

Authorization

sessionAuth
AuthorizationBearer <token>

A session token for an existing account, obtained from POST /auth/login (see the Authentication endpoints) - not an API key. Endpoints marked with this scheme reject API key callers outright, regardless of what that key is granted. Outside the Authentication endpoints themselves, everything requiring this scheme manages dashboard resources (rules, grants, keys, device configuration, command catalogs) and mirrors what a human does in the Nexalware web app - it is not meant to be automated by a third-party integration the way the Device Control and Schedules endpoints are.

In: header

Path Parameters

deviceId*string

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/api/v1/devices/string/credentials/reveal" \  -H "Content-Type: application/json" \  -d '{}'
{  "mqttUsername": "string",  "mqttPassword": "string",  "mqttHost": "string",  "mqttPort": 0,  "wsPort": 0,  "configBlock": "string"}

List devices GET

A dashboard session sees every device on the account. An API key only sees devices its own DeviceGrants actually cover (a direct device grant, or a project-level grant covering everything in that project) - the same scoping every command call is checked against, applied here too so a key never enumerates devices it has no access to. This is the right first call for an agent (SDK or the MCP server's `list_devices` tool) to make: discover which devices this key can act on before calling anything else.

Register a new device POST

Creates the device record in a PENDING state with no MQTT credentials yet call "Generate credentials" separately before it can connect. This is a dashboard/session action, a human registering a device, not something an API key does.