# Authentication

One API key. Your existing Fusara account and balance.

Create an API key in your [Fusara profile](/app/profile). Existing Fusara integration keys work with v3. You do not need a separate API account or wallet.

## Send your key

Use the `Authorization` header on server-to-server requests:

```http
Authorization: Bearer YOUR_API_KEY
```

If your HTTP client requires a named API-key header, use this alternative:

```http
X-API-Key: YOUR_API_KEY
```

Send **one** of these headers, never both. Do not put keys in query strings. Signing in to the Fusara website does not authenticate a request to `/api/v3`; browser cookies are not API credentials.

## Check your connection

Reading your balance verifies the key without starting a generation:

```bash
curl 'https://fusara.ai/api/v3/balance' \
  -H "Authorization: Bearer $FUSARA_API_KEY"
```

`200` confirms that the request was authorized. A zero balance is a valid response. Creating a generation still requires sufficient available funds and access to the selected model.

## What needs authentication?

| Operation | API key |
| --- | --- |
| Read published models and their schemas | Not required |
| Estimate using model settings and text | Not required |
| Estimate with media, references or LoRAs | Required |
| Generate, read runs, list history or cancel | Required |
| Read balance or import media | Required |

An optional key adds resource choices accessible to your account when discovering models. If you supply a key, it must be valid, even on an otherwise public endpoint.

OpenAPI at [`/api/v3/openapi.json`](/api/v3/openapi.json), these guides and the model playground are public. Reading them does not require a key.

## Keep keys on your server

Store the key in an environment variable or your secret manager. Call Fusara from your backend; do not embed a key in a public browser bundle, mobile application, shared URL or copied example.

The examples read `FUSARA_API_KEY` from the environment. They do not require you to paste a key into this documentation.

## Replace or revoke a key

Manage keys from your [profile](/app/profile). When replacing a key, update the applications that use it before revoking the old one. Revoked credentials can no longer authenticate new requests.

Run ownership belongs to the user behind the key. A replacement key for that same user can still read their retained v3 runs; rotation does not create a new history. Sharing a company balance does not grant access to another user's runs.

## Fix an authentication error

- **`401`**: check that the key is present, current and sent with the correct header. Remove accidental whitespace or copied quotation marks.
- **`400` with conflicting credentials**: send only one supported authentication header.
- **A resource returns `404`**: confirm that it belongs to the user behind this key. Inaccessible resources are not exposed through a separate lookup.

For assistance, retain the response's `X-Request-Id` header. Do not include your API key in a support message. [More error guidance](/api/errors).

## Connecting an assistant

MCP can use an API key or a supported account OAuth connection. See [MCP setup](/api/mcp) for the actual endpoint and connection options.