Skip to main content
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.
​
X-API-Key
string
required
API key created in the 0xArchive dashboard.
curl "https://api.0xarchive.io/v1/hyperliquid/orderbook/BTC?depth=1" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
A valid key returns the standard envelope with success, data, and meta: 
{
  "success": true,
  "data": {
    "coin": "BTC",
    "symbol": "BTC",
    "bids": [{ "px": "61077.0", "sz": "0.0003", "n": 1 }],
    "asks": [{ "px": "61078.0", "sz": "11.73086", "n": 32 }],
    "mid_price": "61077.5"
  },
  "meta": { "request_id": "req_8f3c1a9e2b7d4f60" }
}
A missing or invalid key returns 401 with success: false and an error object. See Error handling. Keep meta.request_id (or the x-request-id header) from any response when you need support. 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.

Free tier, no card

Get a key and run a real call

New accounts start free, no card required. Create a key in the dashboard and paste it into any example here.

Create a key →

​
Key Handling

1

Create a key in the dashboard

Use the dashboard for standard key creation and rotation.
2

Store it outside source control

Use environment variables or your secret manager. Do not paste keys into checked-in examples.
3

Send it on market-data calls

Authenticated REST market-data requests use X-API-Key. WebSocket examples use the key during connection setup.
4

Rotate when access changes

Replace old keys when a workflow, machine, or teammate no longer needs access.

​
Wallet Flows

The OpenAPI contract includes SIWE routes for wallet-signature account verification. Use /v1/auth/web3/challenge to create the SIWE challenge, sign it in the wallet environment, then submit the signed message to POST /v1/auth/web3/verify. Use these when an account flow needs wallet ownership confirmed before issuing an X-API-Key credential or browser session. SIWE verification does not give 0xArchive custody or transaction control. 0xArchive never requests private keys or seed phrases, cannot move funds, cannot approve transactions, and cannot place or cancel venue orders.

​
Credential Checklist

Use this checklist before wiring credentials into a backend, script, notebook, MCP server, Skill, or coding-agent session.
SurfaceCredential rule
REST market dataSend X-API-Key on every authenticated request. Use OXARCHIVE_API_KEY as the shell variable in docs examples.
Health checkGET /health is unauthenticated liveness; it does not confirm key validity.
WebSocketConfigure the same API key during connection setup, then keep request and stream logs free of the raw key.
CLIExport OXA_API_KEY for oxa commands.
MCP Server and SkillPass OXARCHIVE_API_KEY through the host environment or secret store.
SDKsRead the key from the runtime environment or secret manager before constructing the client.
Browser appsCall your own backend; do not expose a 0xArchive API key directly to users.
SIWE-confirmed accessUse /v1/auth/web3/challenge, POST /v1/auth/web3/verify, and web3 account routes only when credential issuance 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.

SIWE verification

Wallet-signature account verification before issuing X-API-Key credentials.

Error handling

Handle missing keys, invalid keys, rate limits, and request IDs.
Last modified on June 28, 2026