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.
string
required
API key created in the 0xArchive dashboard and loaded from your runtime environment.
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:meta.request_id or the x-request-id response header when troubleshooting.
Missing or invalid key
A missing or invalid key returns HTTP401 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:
request_id sits at the top level, not under meta, and matches the x-request-id response header. 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.
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. 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.