> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlaso.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Devices & hardware

> Put Atlaso memory on an ESP32, a robot, or a whole fleet — safely — with per-device credentials.

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.

```
device ──auth──► your backend ──atlk_ key + subject──► 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.

<Warning>
  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.
</Warning>

## 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.

<Steps>
  <Step title="Mint from your backend">
    ```bash theme={null}
    curl -X POST https://mcp.atlaso.ai/developer/v1/device-credentials \
      -H "X-Atlaso-Project-Key: $ATLASO_KEY" \
      -H "Content-Type: application/json" \
      -d '{"subject": "robot_42", "label": "Unit 42", "group_id": "batch-2026"}'
    ```

    ```json theme={null}
    {
      "credential_id": "…",
      "full_token": "atldev_…_…",
      "subject": "robot_42",
      "external_device_id": null,
      "existing": false
    }
    ```

    `full_token` is returned once for a newly minted credential.
  </Step>

  <Step title="Flash the token to the device">
    The device authenticates directly to Atlaso with it:

    ```http theme={null}
    Authorization: Bearer atldev_<id>_<secret>
    ```

    No subject header — the credential already pins the subject. Sending one
    anyway returns `400`.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### 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:
  ```bash theme={null}
  curl -X POST https://mcp.atlaso.ai/developer/v1/device-credentials/revoke \
    -H "X-Atlaso-Project-Key: $ATLASO_KEY" \
    -H "Content-Type: application/json" \
    -d '{"group_id": "batch-2026"}'
  ```
* 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

|                         | Limit                               |
| ----------------------- | ----------------------------------- |
| Credentials per subject | 50                                  |
| Credentials per project | 100,000                             |
| Batch enroll size       | 500                                 |
| Per-credential rate     | 60 `remember`/min, 120 `recall`/min |

More in [Limits & quotas](/build/limits).