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

# Authentication

> API keys, test vs. live mode, permission scopes.

Robase uses **bearer API keys**. Pass your key in the `Authorization` header on every request:

```http theme={null}
Authorization: Bearer rb_live_7f3a...
```

## Key formats

Every key has the format `rb_<env>_<32-char-token>`. The `<env>` segment tells you at a glance what the key does:

| Prefix      | Mode | Behavior                                                                             |
| ----------- | ---- | ------------------------------------------------------------------------------------ |
| `rb_live_*` | Live | Real carriers, real money, real delivery receipts.                                   |
| `rb_test_*` | Test | Simulator: magic numbers produce deterministic outcomes. Does not debit your wallet. |

<Tip>
  Keep separate keys per environment. Never ship a `rb_live_` key inside a mobile app or browser bundle — test keys are safe to expose in CI-only test suites.
</Tip>

## Permission scopes

When you create a key you pick its permission:

<ParamField body="permission" type="string" required>
  One of:

  * **`full`** — all endpoints (default). Sends + reads + admin (templates, sender IDs, webhooks, domains).
  * **`sending`** — `POST /v1/sms`, `POST /v1/emails`, `POST /v1/sms/batch`, `POST /v1/emails/batch` only. Read operations fail with `permission_error`.

  Use `sending` keys for servers that only emit messages — no dashboard, no template management. If that key leaks you minimize the blast radius.
</ParamField>

## Revoking keys

Keys are revoked instantly from the dashboard (**API keys → Revoke**). Revoked keys return `401 authentication_error` on the next request.

We hash keys with argon2id + a server-side pepper, so even a database dump doesn't hand an attacker your secrets. But revocation is still the fastest remediation if you think a key leaked.

## Session authentication (dashboard only)

Dashboard endpoints (`/dashboard/*`) use a session cookie set by `/auth/login` — not an API key. You rarely need this unless you're embedding the dashboard somewhere custom.

## Idempotency + replay

Auth has nothing to do with idempotency — see [Idempotency](/concepts/idempotency) for how we de-duplicate retries. The two concepts are orthogonal: a retried request with the same `Idempotency-Key` still needs a valid API key.