> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication And API Keys

> Authenticate 0xArchive REST, WebSocket, SDK, CLI, and agent clients with X-API-Key.

0xArchive clients authenticate with an API key. Send it in the `X-API-Key` header for authenticated REST market-data requests and configure the same key in SDK, CLI, MCP, and WebSocket clients.

<ParamField path="X-API-Key" type="string" required>
  API key created in the 0xArchive dashboard.
</ParamField>

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/hyperliquid/orderbook/BTC?depth=1" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

`GET /health` is an unauthenticated liveness check. Use it to check service reachability, not whether a key is valid. A market-data route with `X-API-Key` is the right first authentication test.

## Key Handling

<Steps>
  <Step title="Create a key in the dashboard">
    Use the [dashboard](https://www.0xarchive.io/dashboard/) for standard key creation and rotation.
  </Step>

  <Step title="Store it outside source control">
    Use environment variables or your secret manager. Do not paste keys into checked-in examples.
  </Step>

  <Step title="Send it on market-data calls">
    Authenticated REST market-data requests use `X-API-Key`. WebSocket examples use the key during connection setup.
  </Step>

  <Step title="Rotate when access changes">
    Replace old keys when a workflow, machine, or teammate no longer needs access.
  </Step>
</Steps>

## Wallet Flows

The OpenAPI contract includes wallet authentication routes for SIWE-style flows and wallet-managed keys. Use these when you are building account automation around a wallet rather than managing keys manually in the dashboard.

## Credential Packet

Use this packet before wiring credentials into a backend, script, notebook, MCP server, Skill, or coding-agent session.

| Surface               | Credential rule                                                                                                  |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- |
| REST market data      | Send `X-API-Key` on every authenticated request. Use `OXARCHIVE_API_KEY` as the shell variable in docs examples. |
| Health check          | `GET /health` is unauthenticated liveness; it does not confirm key validity.                                     |
| WebSocket             | Configure the same API key during connection setup, then keep request and stream logs free of the raw key.       |
| CLI                   | Export `OXA_API_KEY` for `oxa` commands.                                                                         |
| MCP Server and Skill  | Pass `OXARCHIVE_API_KEY` through the host environment or secret store.                                           |
| SDKs                  | Read the key from the runtime environment or secret manager before constructing the client.                      |
| Browser apps          | Call your own backend; do not expose a 0xArchive API key directly to users.                                      |
| Wallet-managed access | Use wallet-auth routes only when key lifecycle should follow wallet ownership.                                   |

## Production Checklist

Use one key per environment when possible: local development, CI, staging, production, and agent/tooling work should not all share the same credential. That separation makes rotation and debugging much easier when a script misbehaves or a teammate leaves a workflow.

For server code, read the key from an environment variable or secret manager at process start. For notebooks, shells, CLI jobs, MCP servers, and coding-agent sessions, export the key into the session environment and keep it out of prompt transcripts. For browser clients, call your own backend rather than exposing a 0xArchive key directly to users.

When an authentication error occurs, log the method, path, venue family, symbol, status code, and request handle. Use `meta.request_id` when a response envelope exposes it, or the `x-request-id` header when an auth response returns a simpler JSON body. Do not log the key. If the same key works in curl but fails in a client, compare the exact header name first: REST market-data requests use `X-API-Key`.

## Interface Notes

The CLI uses `OXA_API_KEY`. The MCP Server and Skill examples use `OXARCHIVE_API_KEY`. REST examples in these docs use `OXARCHIVE_API_KEY` as the shell variable and send it as `X-API-Key`. Keep the variable name that matches the product surface you are using, but keep the HTTP header stable for authenticated market-data requests.

<CardGroup cols={2}>
  <Card title="Wallet automation" icon="wallet" href="/wallet-automation">
    SIWE challenge creation, wallet-managed keys, and payment-aware automation.
  </Card>

  <Card title="Error handling" icon="triangle-alert" href="/errors">
    Handle missing keys, invalid keys, rate limits, and request IDs.
  </Card>
</CardGroup>