# Authentication

> Where API keys come from, which kinds work, and how to send one.

## Get a key

API keys are created on the [API Keys page](https://app.alphaneural.io/profile/me?tab=api-keys) (Profile, then API Keys). When that page loads and you have no key for the public catalogue, one is created for you, so most accounts already have a key. You can also create one without leaving the [Quickstart](https://app.alphaneural.io/docs/quickstart).

When you create a key you choose what it can reach:

| Scope | Can call |
|---|---|
| Public | Every model in the public catalogue. Use this one for the examples in these docs. |
| Private | The models you have deployed yourself. |
| Standalone | The one deployment you pick when you create the key. |

The same page also issues Gitea keys, which give git access to model and dataset repositories. They are not API keys, and the API refuses them.

## Send it

Send the key as a bearer token:

```http
Authorization: Bearer sk-...
```

This is the only header the API reads a key from. The OpenAI SDKs send it for you when you pass `api_key` in Python or `apiKey` in TypeScript.

| Response | When |
|---|---|
| `401` `missing API key` | No `Authorization` header, or an empty one. |
| `401` `unknown or inactive API key` | The key does not exist, has been deleted or deactivated, or is a Gitea key. |

## What the key controls

The API looks your key up to find your account, then forwards your call to the gateway with the same key. Whatever applies to the key therefore applies to the call: the models its scope reaches, and any budget or rate limit set on it. A Standalone key asked for a model outside its scope gets the gateway's own error back, unchanged (see [Errors](https://app.alphaneural.io/docs/errors)).

Threads and cost traces belong to your account, not to one key. Any of your keys can continue your threads and read your traces.

## Keep keys safe

- A key stays readable on the API Keys page for as long as it exists, so anyone signed in to your account can copy it. Protect the account accordingly.
- Keep keys on the server, in environment variables or a secrets manager. Never ship one inside a browser page or a mobile app.
- If a key leaks, regenerate it on the API Keys page. Regenerating issues a new value and revokes the old one.
- Use a separate key per project or environment, so that revoking one does not break the others.

## GraphQL

API keys do not authenticate the GraphQL API at `https://backend.alfnrl.io/query`. The catalogue query on [Models](https://app.alphaneural.io/docs/models) needs no authentication at all; the rest of that API serves the web app's signed-in session.