Passwords & device access

Manage cloud passwords and allowed device IDs for a saved configuration. Every request requires the owner's Client API key. These access records are unavailable for an in-memory Business API configuration.

Adding the first password or device ID automatically enables that cloud access mode on the configuration. Removing entries does not automatically turn the mode off; change configuration-level access settings in the panel.

Allow device IDs

POST /api/v1/configs/{config_key}/device-ids

Save this as access.json:

{
  "device_ids": ["AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"],
  "note": "My devices",
  "is_active": true
}

With the quickstart variables set, send it:

curl --fail-with-body --request POST "$API_BASE/configs/$CONFIG_KEY/device-ids" \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header "X-API-Key: $CLIENT_API_KEY" \
  --data-binary @access.json

Whitespace is trimmed and letters are uppercased on creation. Duplicate IDs within the request are deduplicated. An ID already saved for this configuration causes 422. The owner's configured device access limit still applies.

Success returns configuration_id, config_unique_key, added_count, and device_ids. Each record has a numeric id, the hardware device_id, the access fields above, and timestamps.

List, update, or remove device access

The final URL segment is the numeric record id returned by the API, not the 32-character hardware ID. Updating a hardware ID requires exactly 32 hexadecimal characters and must not duplicate another entry.

For example, to disable access record 42, send {"is_active":false} to PATCH /api/v1/configs/{config_key}/device-ids/42.

Create passwords

POST /api/v1/configs/{config_key}/passwords

{
  "passwords": ["Secret123", "Secret456"],
  "type": "reusable",
  "note": "Subscribers",
  "is_active": true
}

Send this body using the same request pattern as device access, with /passwords as the final path segment.

Success returns added_count and a passwords array, plus configuration identifiers. Password values are returned to the owner; treat these responses as secrets. Each record also includes id, access fields, used_device_id, used_at, and timestamps.

Generate passwords automatically

Use the same creation endpoint, omit passwords, and send:

{
  "generate_multiple": true,
  "count": 3,
  "type": "one_time",
  "delete_after_used": true
}

count must be 1–100 and is only accepted when generate_multiple is true. Generated passwords are returned in the response. The owner's configured password count limit applies to both creation modes.

List, update, or remove passwords

Use the numeric record id in the URL. For example, send {"is_active":false} to PATCH /api/v1/configs/{config_key}/passwords/42 to disable one record. All successful access operations return HTTP 200. Missing access records return 404; invalid fields return 422.

What happens when the app uses an access record?

Use the device ID displayed in the app for device_ids. Do not send the device-registration ID, a database device-row ID, or your Client API key.

Cloud passwords and allowed-device records are checked through the app's signed authentication flow. Local password/HWID modes use the imported configuration instead. After enabling a cloud mode on a saved configuration, update or reimport the configuration so recipient apps know to use it. Keep the configuration's access mode restricted; open access does not carry cloud locks.

A one_time password permits one successful authentication, not permanent rebinding to the first device. It is then marked used and rejected on later authentication attempts, including attempts from that same device. With delete_after_used: true, it is deleted instead. An allowed-device record with that flag is deleted after successful device authentication.

The app can continue using the authorization token it already received until that token expires. Disabling or deleting the underlying access record affects future authentication; it is not an immediate revocation of an issued token. Access-record expire_date is inclusive through the end of that date in the panel's configured timezone and also determines token expiry. Without an entry expiration, the current server issues a token lasting up to one year. Use reusable passwords or persistent device records for recurring access.