# Authentication

Every `/v1` request carries two credentials:

| Header | Holder | Purpose |
| --- | --- | --- |
| `X-Api-Key: fin_…` | Your backend | Identifies your registered integration. |
| `Authorization: Bearer <access JWT>` | The end user, forwarded by your backend | Identifies the user the request acts for. |

Get your partner key from the deployment operator. Keys are shown once when minted. To rotate,
mint a replacement, update your backend, and revoke the old key; both remain valid until
revocation. Revocation may take up to 30 seconds to reach every replica's credential cache.
Keep partner keys out of browser code and public repositories.

Your identity integration obtains and refreshes access tokens from the configured trusted
issuer. Fin verifies those tokens; it does not issue human login or refresh tokens. A partner
key alone cannot act for a user. A valid key with no user token receives `401`.

First call [`users.ensure`](/api-reference/users/ensure) with the verified user's token. It
creates their Fin account if needed and returns its internal `userId`. Use that UUID in paths,
not the token's `subject` or a wallet address. A path naming another user receives
`403 subject_mismatch` before resource lookup. Account-dependent calls before provisioning
receive `412 account_not_provisioned`; provisioning cannot re-enable a disabled account.

For browser applications, your backend owns the session, token renewal and request proxy.
Attach both credentials when forwarding to Fin. User logout or token expiry does not delete
history or cancel work already admitted by Fin.