# Authentication

Every request carries your organization's API key as a Bearer token. Keys are shown once at mint time and stored hashed server-side.

## Bearer token

```
Authorization: Bearer oo_live_<secret>
```

Keys must start with `oo_live_`. Invalid format returns `401 invalid_key`.

## Member attribution

For per-member soft limits and usage breakdowns, pass your internal user UUID:

```
X-Member-User-Id: <uuid>
```

This does not forward identity to upstream model providers.

## Scopes

| Scope | Endpoints |
|-------|-----------|
| `chat` | POST api-v1-chat |
| `images` | POST api-v1-images |
| `video` | POST api-v1-video, GET api-v1-video |
| `audio` | POST api-v1-audio |
| `usage` | GET api-v1-models, GET api-v1-usage |
| `files` | GET/POST api-v1-files |
| `apps` | GET/POST api-v1-apps |
| `assets` | GET/DELETE api-v1-assets |
| `jobs` | GET api-v1-jobs |
| `webhooks` | GET/POST api-v1-webhooks |
| `billing` | GET/POST api-v1-billing |

Keys minted in the dashboard include this set. `jobs` also accepts a key that only has `video`. `billing` also accepts a key that only has `usage`.

## Model allowlists

Keys can optionally be pinned to specific model IDs at mint time.

## Key hygiene

- Store keys in a secrets manager, never in client-side source committed to git.
- Rotate keys if exposed; revoke immediately in the admin console.
- Use separate keys per environment (staging vs production).