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

# Agent context: auth and response envelope

> Auth and response-envelope rules for generated 0xArchive clients, including API-key placement, hosted MCP OAuth, success flags, errors, and response metadata.

Auth:

* Base URL: `https://api.0xarchive.io`
* REST header: `X-API-Key`
* Env vars: use `OXARCHIVE_API_KEY` for REST examples, SDKs, and Skill workflows; use `OXA_API_KEY` for the `oxa` CLI. WebSocket uses the API key during connection setup.
* Hosted MCP: use the client's built-in OAuth flow with no 0xArchive API key; the authorization server is `https://auth.0xarchive.io` and the scope is `mcp:market.read`. The client owns the OAuth bearer header; do not send `X-API-Key` to `https://mcp.0xarchive.io/mcp`.

API-key, WebSocket, and hosted-MCP credentials are separate transport paths. Use the documented WebSocket handshake for WebSocket clients, and use the exact tool name and input schema advertised by the connected MCP server rather than inferring either from a REST route.

Response envelope for most market-data endpoints:

* `success`: boolean
* `data`: route payload
* `meta.count`: item count
* `meta.next_cursor`: pagination cursor when present
* `meta.request_id`: log this for debugging and support

Resource-specific data-quality coverage routes such as `/v1/data-quality/coverage/{exchange}/{symbol}` can return bodies shaped around `exchange`, `symbol`, `data_types`, and coverage fields without `success`, `data`, or `meta`. Parse those routes from their endpoint contract instead of forcing the market-data envelope.

Response rules:

* Generated clients should parse `data` from the endpoint-specific [OpenAPI schema](/openapi).
* Log `meta.request_id` for success pages, failed attempts, and paginated windows when the response exposes it.
* For data-quality coverage bodies without `meta`, store method, path, parameters, status, the coverage payload, and any request ID exposed by the client or transport.
* Keep numeric-looking market fields decimal-safe unless a generated type states otherwise.
* Preserve venue family with stored records because the same field name can have different meaning across Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, and Lighter.

Error responses are flat: `{success: false, code, error_code, error, request_id}`. Error clients should log method, path, status, `error_code`, and the top-level `request_id`.

## Next step

Add the data-quality preflight a job needs with [Agent context: freshness checks](/agent-context/freshness-checks).


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