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

Send your API key in the `X-API-Key` header on every authenticated REST request. Each endpoint page states whether its 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>

Create, store, and rotate keys as described in [API keys and credential safety](/authentication). Load the key from `OXARCHIVE_API_KEY` in your environment; do not paste the raw key into source code.

## Authenticated request

Use a bounded request such as a one-level BTC order book to confirm the key works:

```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, inside the envelope described on [Responses](/responses). Keep `meta.request_id` or the `x-request-id` response header when troubleshooting.

## Missing or invalid key

A missing or invalid key returns HTTP `401` with `error_code` `unauthorized`. Treat the status as the control signal and the JSON body as the debugging payload. A request without a key returns:

```json theme={"theme":"github-dark"}
{
  "success": false,
  "code": 401,
  "error_code": "unauthorized",
  "error": "Missing authentication credentials. Provide X-API-Key header or Bearer token.",
  "request_id": "c4fcb5bf-329c-4dd0-acd4-8276c2e641b6"
}
```

Error bodies are flat: `request_id` sits at the top level, not under `meta`, and matches the `x-request-id` response header. [Errors](/errors) lists every `error_code` and the retry behavior for each.

On a `401`, compare the header name, the key source, the `error_code`, and the request ID before you call again. Repeating the same unauthorized request does not repair the key, so fix authentication first and keep retries bounded as described in [Rate limits](/rate-limits).

## 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; a route's operation-level security takes precedence over the default rule.

SIWE challenge, verification, and API-key management routes use wallet-signature verification instead of the market-data API-key check. Follow the route's endpoint page and [Wallet access 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.

These account and payment flows do not replace `X-API-Key` on authenticated market-data endpoints. Every route's authentication state is listed in the [Endpoint reference](/api-reference).

## Next step

Shape your first data request with [Request parameters](/rest-api/parameters).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.