# Authentication & permissions

Authenticate every REST request with an Interfold API key.

## Headers

Bearer authentication is recommended:

```http
Authorization: Bearer <api-key>
```

The equivalent API-key header is also accepted:

```http
X-API-Key: <api-key>
```

A missing or invalid key returns `401 Unauthorized` with the REST error
envelope: `{"error":{"code":"unauthorized","message":"..."}}`.

## Keep keys private

API keys are server-side credentials. Do not ship them in browser code, commit
them to project files, paste them into chat, or include them in public logs.
Create and revoke keys from the dashboard.

## Permissions

Manual keys have one fixed permission:

| Permission | Allows                                                                                                            |
| ---------- | ----------------------------------------------------------------------------------------------------------------- |
| `READ`     | Reads, including file contents, secret values, migration receipts, and MCP read tools.                            |
| `WRITE`    | Every read plus creation, updates, uploads, deployments, generic database queries, migration apply, and deletion. |

Read-only keys allow `GET`, `HEAD`, and `OPTIONS`. They also allow MCP
transport requests whose selected tool is read-only.

`POST /v0/sites/:siteId/databases/:databaseId/query` requires `WRITE`, even
when its SQL only reads data, because the generic query surface can also change
data and schema.

Other writes return `403 Forbidden` before the operation runs. Permissions
cannot be changed after creation; revoke the key and create a replacement.

## Account scope

Each API key belongs to exactly one account. Use
[Get current account](/api-reference/accounts#get-current-account) to resolve
that account without storing a second account identifier.

Resource authorization still applies. A valid key cannot operate on resources
owned by another account.

## Browser-only operations

Some dashboard operations require an interactive user identity and are not part
of the API-key contract. These include managing API keys, account membership,
billing, and user-owned agent approvals.

The operation sections in this reference describe the supported API-key surface.