Skip to main content
Atlaso Build is built for physical products too — a companion robot that remembers its owner, a kiosk, an ESP32 sensor that learns a room. There are two patterns; pick by how much you trust the device.

​
Pattern 1 — proxy through your backend (default)

The device talks to your server; your server holds the atlk_ project key and calls Atlaso.
  • The project key never leaves your server.
  • Your backend maps each device to a subject and does its own device auth.
  • Best when the device already has a secure channel to your backend.
Never put a project key (atlk_…) on device flash. One extracted key can read and write every subject in the project. If the key has to live near the device, use Pattern 2 instead.

​
Pattern 2 — per-device credentials

Mint a credential whose subject is baked in, and flash that to the device. It can only touch its own subject’s memory, and you can revoke it individually.
1

Mint from your backend

full_token is returned once for a newly minted credential.
2

Flash the token to the device

The device authenticates directly to Atlaso with it:
No subject header — the credential already pins the subject. Sending one anyway returns 400.
3

The device remembers & recalls its own memory

Same POST /memories and GET /recall calls as the API reference, just with the bearer instead of key + subject.

​
Fleets

  • Enroll up to 500 devices per call with POST /device-credentials/batch (pass an Idempotency-Key so a retried enrollment doesn’t double-mint).
  • Group devices with group_id, then revoke the whole fleet in one call:
  • Revoke a single device by credential_id. Revocation is immediate — the next call from that device gets 401.

​
What a device credential can’t do

A device credential is deliberately minimal: it can only remember, recall, and delete for its own subject. It can never mint other credentials, create projects, or read another subject — so a physically compromised device leaks only its own memory.

​
Limits worth knowing

More in Limits & quotas.