Devices

A device is the unit that actually connects: a phone, laptop, server, or embedded client, owned by exactly one consumer account and identified by its public key. The /consumer/v1/devices family is the full lifecycle.

Registration and authorization

• POST /consumer/v1/devices registers a device (name + public key) on the authenticated account; GET /consumer/v1/devices lists them.
• Projects that require approval get a gate: GET /consumer/v1/devices/pending lists devices awaiting a decision, and POST /consumer/v1/devices/{id}/authorization/approve (or …/reject) resolves each one. The decision history is queryable at GET /consumer/v1/devices/{id}/authorization-events.

Liveness and sessions

Connected devices report in with POST /consumer/v1/devices/{id}/heartbeat; their VPN session history is at GET /consumer/v1/devices/{id}/sessions and transfer accounting at GET /consumer/v1/devices/{id}/usage. An account (or your support tooling) can cut a live device off with POST /consumer/v1/devices/{id}/force-disconnect.

Key hygiene

Device keys rotate without re-enrollment: POST /consumer/v1/devices/{id}/rotate-key installs a new public key, and GET /consumer/v1/devices/{id}/key-rotations shows the rotation history.

Network roles

A device can be more than a client:

• Exit node — the …/exit-node/enable, approve, disable, and revoke operations manage a device's life as an exit for other devices in its network.
• Subnet routes — PUT /consumer/v1/devices/{id}/advertised-routes advertises routes the device can relay (and DELETE withdraws them).
• Network map — POST /consumer/v1/devices/{id}/map is how a connected device receives its current peer map.

Reference

Full request/response shapes for every operation above are in the generated API reference under the consumer plane's devices family. To drive devices from application code, start with an SDK quickstart.