> ## 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.

# REST authentication

> Authenticate 0xArchive REST requests with X-API-Key, recognize route-specific exceptions, and troubleshoot HTTP authentication failures.

Most 0xArchive REST endpoints require an API key in the `X-API-Key` request header. Each native endpoint page states whether the route requires the key, is public, uses wallet-signature verification, or uses an x402 payment flow.

<ParamField header="X-API-Key" type="string" required>
  API key created in the 0xArchive dashboard and loaded from your runtime environment.
</ParamField>

## Authenticated request

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

A successful authenticated request returns the response documented on its endpoint page. Keep `meta.request_id` or the `x-request-id` response header when troubleshooting.

## Missing or invalid key

A missing or invalid key normally returns HTTP `401`. Treat the status as the control signal and the compact JSON body as the debugging payload.

```json theme={"theme":"github-dark"}
{
  "code": 401,
  "error": "Missing or invalid API key. Provide X-API-Key header."
}
```

This compact body does not include the standard response envelope. Store the `x-request-id` response header when `meta.request_id` is absent. See [Errors and request IDs](/errors) for logging and retry behavior.

## Route-specific exceptions

`GET /health` is public and checks service reachability only. It does not verify an API key. Other exceptions are marked on their endpoint pages and in the OpenAPI security declaration. Do not assume a route inherits the default authentication rule when its operation-level security says otherwise.

SIWE challenge, verification, and API-key management routes use wallet-signature verification instead of the normal market-data API-key check. Follow the route-specific endpoint page and [SIWE verification](/wallet-automation). Never send a private key or seed phrase.

`POST /v1/web3/subscribe` is an x402 payment flow, not SIWE verification. Send the signed `payment-signature` header required by its endpoint page and follow [wallet access and x402](/wallet-automation).

These account and payment flows do not replace `X-API-Key` on authenticated market-data endpoints.

## First authentication check

<Steps>
  <Step title="Load the key from the environment">
    Use `OXARCHIVE_API_KEY` in REST examples. Do not paste the raw key into source code.
  </Step>

  <Step title="Call one small authenticated route">
    Use a bounded request such as the one-level BTC order-book example above.
  </Step>

  <Step title="Inspect the exact failure">
    On `401`, compare the header name, key source, JSON error code, and request identifier before retrying.
  </Step>

  <Step title="Keep retries bounded">
    Fix authentication before retrying. Repeating the same unauthorized request does not repair the key.
  </Step>
</Steps>

## Shared request rules

<CardGroup cols={3}>
  <Card title="Rate limits and credits" icon="gauge" href="/rate-limits">
    Plan request volume, concurrency, and retry behavior.
  </Card>

  <Card title="Responses" icon="list-tree" href="/responses">
    Parse HTTP statuses and response bodies correctly.
  </Card>

  <Card title="Errors and request IDs" icon="triangle-alert" href="/errors">
    Keep request identifiers and decide when to retry or stop.
  </Card>
</CardGroup>

## Related guidance

<CardGroup cols={2}>
  <Card title="API keys and credential safety" icon="key-round" href="/authentication">
    Create, store, separate, and rotate credentials safely.
  </Card>

  <Card title="Endpoint reference" icon="book-open-check" href="/api-reference">
    Find the route, parameters, authentication state, and response schema.
  </Card>
</CardGroup>