# Authentication

> Two kinds of bearer key open the Memory API. Each call names the credential in the Authorization header.

```header
Authorization: Bearer $HARNY_APP_KEY
X-Harny-User: <user>
```

| Credential | Opens |
|---|---|
| **App key** (`fsa_`) | Ingest, completion, recall, data points, audiences, users and usage. The key selects one app, so the app id is never sent in a request body. Send `X-Harny-User` to name the user the call acts as. Your application holds this key. |
| **User key** (`fsk_`) | The memory routes for the one user the key names. It needs no `X-Harny-User` header, and it never reads another user's memory. |

A call with no `Authorization` header, or with a key that is unknown or revoked, returns `401 unauthorized`. One answer covers all three, so a refusal never says which keys exist.

## Where keys are created

App keys are created in the console, by the setup command your coding agent runs, or by `POST /v1/auth/provision`, which creates an app and its first key with no key needed. Each of them shows the key value once. Store it in an environment variable and never in code, chat or a commit.

For a fresh app: create the key, keep it in `HARNY_APP_KEY`, and start with the [Quickstart](/docs/memory-api/quickstart). Your coding agent can do the same with no account by following [harny.ai/auth.md](https://harny.ai/auth.md).

Call the API from your server. A key in a browser is exposed to its users.

## Naming the user

An app key acts as the user named in `X-Harny-User`. The value is the id your application already uses for that person. A body `identity` never selects the user: when you send one, it must equal the user the call acts as. Any other value returns `403 identity-mismatch`.

## Refusals

| Status | Code | When |
|---|---|---|
| 401 | `unauthorized` | The key is missing, unknown or revoked. |
| 403 | `identity-mismatch` | A body `identity` differs from the user the call acts as. |