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

# Authentication

> Authenticate with an organization-scoped bearer API key.

The CreatorAudit API authenticates every request with an organization API key sent
as a bearer token. Keys are scoped to a single organization, so every response is
limited to the data that organization owns.

## Create a key

API keys are created on the dashboard:

<Steps>
  <Step title="Open the dashboard">
    Go to [app.creatoraudit.com](https://app.creatoraudit.com) and sign in.
  </Step>

  <Step title="Create a key">
    Open the [API keys page](https://app.creatoraudit.com/app/api-keys) and create a new
    key. Give it a recognizable name (it appears in `whoami`).
  </Step>

  <Step title="Copy it now">
    The full key is shown only once at creation time. Copy it and store it in your
    secret manager — you cannot retrieve it again later.
  </Step>
</Steps>

<Warning>
  The key grants full access to your organization's data. Treat it like a password. If a
  key is exposed, disable it and create a replacement.
</Warning>

## Send the token

Add an `Authorization` header with the `Bearer` scheme to every request:

```
Authorization: Bearer YOUR_API_KEY
```

```bash theme={null}
curl https://api.creatoraudit.com/v2/accounts \
  -H "Authorization: Bearer YOUR_API_KEY"
```

`GET /v2/health` and `GET /v2/meta` are unauthenticated and need no header; every
other endpoint requires the bearer token.

### Scopes

Each key carries a set of scopes — `read`, `write`, and `admin` — and keys are
issued with all three by default. Read endpoints (`GET`) require no special scope.
Mutating endpoints (`POST`/`PATCH`/`PUT`/`DELETE`) require the `write` scope
(`admin` implies `write` implies `read`). A key lacking the required scope gets a
`403` with `code: INSUFFICIENT_SCOPE`.

## Verify your key

`GET /v2/whoami` echoes the organization and key name the token resolves to —
a quick way to confirm a key works and which org it is bound to:

```bash theme={null}
curl https://api.creatoraudit.com/v2/whoami \
  -H "Authorization: Bearer YOUR_API_KEY"
```

```json theme={null}
{
  "data": {
    "type": "whoami",
    "organization_id": "0b3f2c14-9a6d-4f1e-8b2a-1c2d3e4f5a6b",
    "api_key_name": "Production key"
  }
}
```

## When authentication fails

A missing or invalid key returns `401` with `code: UNAUTHORIZED`. An inactive key
or subscription returns `403` with `code: FORBIDDEN`. Both follow the RFC 9457
[error shape](/api-reference/errors):

```json theme={null}
{
  "type": "urn:creatoraudit:error:unauthorized",
  "title": "Unauthorized",
  "status": 401,
  "detail": "Missing or invalid API key.",
  "code": "UNAUTHORIZED",
  "instance": "/v2/whoami",
  "request_id": "8f1c2a4e-…"
}
```

## Key hygiene

* **Keep it secret.** Never commit keys to source control, embed them in
  client-side code, or paste them into logs or screenshots.
* **Call from a server.** Keep the key on your backend and proxy requests; do not
  ship it to browsers or mobile apps.
* **Use one key per integration.** Separate keys make it easy to disable one
  without disrupting the others, and `whoami` tells you which is calling.
* **Rotate without downtime.** Create a new key, deploy it, confirm traffic has
  moved over, then disable the old one on the dashboard. Disabled keys return
  `403`.

For more on org scoping and key hygiene, see
[Security & data handling](/security).

Continue with [Errors](/api-reference/errors) and
[Rate limits](/api-reference/rate-limits).
