# Authentication

> API keys, their scopes, and the rules every call goes through.

Every call to the API and the MCP server is authenticated with a workspace API key sent as a bearer token:

```http
Authorization: Bearer bxk_<prefix>.<secret>
```

## Creating a key

Owners and admins create keys in **Settings → API keys**. A key belongs to one workspace and acts on behalf of the member who created it. The secret is shown once; Browlix keeps only a hash, so a lost secret cannot be recovered — revoke the key and create a new one.

## What a key may do

A call succeeds only if **both** hold the capability the operation needs (shown on each [reference](https://browlix.com/en/docs/reference) page):

- the key's scopes, chosen when it was created, and
- the member behind the key, with their current role and group scope.

If the member's role is lowered or they leave the workspace, the key loses that access at once. A key never sees profiles outside its member's groups and never receives proxy passwords, cookies or other stored secrets.

## Errors

| Situation | Code | HTTP |
|---|---|---|
| Missing, malformed, revoked or expired key | `UNAUTHENTICATED` | 401 |
| Valid key without the needed capability | `FORBIDDEN` | 403 |
| Too many requests for this key | `RATE_LIMITED` | 429 |

## Keeping keys safe

- Store keys in environment variables or your secret manager; the SDK and CLI never read them from files or the command line on their own.
- Use a separate key per app or agent, with only the scopes it needs, so you can revoke one without stopping the others.
- Browlix redacts anything shaped like a key in feedback tickets and error messages, but do not paste keys into prompts or logs.