Skip to main content

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.

Response parsing should preserve the payload and the meta context that makes it usable later. Use Example Responses for schema-backed payload examples, Schemas for shared field notes, and OpenAPI for endpoint-specific generated schemas. Most market-data routes return a JSON envelope with success, data, and meta. Some auth, system, wallet, and data-quality routes have resource-specific bodies; use the REST reference and response headers for the exact response shape of a specific endpoint.

​
Success Envelope

{
  "success": true,
  "data": [],
  "meta": {
    "count": 100,
    "next_cursor": "1704067200123_456789",
    "request_id": "550e8400-e29b-41d4-a716-446655440000"
  }
}
FieldClient behavior
successTreat false as an application-level failure even when a JSON body exists
dataParse according to the endpoint-specific schema
meta.countUse for returned item count, not necessarily total available records
meta.next_cursorUse for pagination when present
meta.request_idLog on success and failure for debugging and support

​
Response Handling Packet

Use this packet before a client, agent, or parser stores response data.
StepRequired handling
HTTP statusDecide retry, auth repair, fail-fast behavior, or support escalation from the status class.
successTreat success: false as an application failure even when the HTTP response contains JSON.
dataParse from the endpoint-specific OpenAPI schema, not from a nearby example.
meta.request_idStore request IDs for successes, failed attempts, and paginated pages; for resource-specific auth, system, wallet, or data-quality bodies, store any request ID the route, response header, or client exposes.
meta.next_cursorKeep cursor, route, symbol, query parameters, and request ID together for resumable jobs.
Venue contextPersist venue family and symbol style beside records so joins do not mix Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter.
Decimal fieldsKeep numeric-looking market fields decimal-safe until the application boundary.

​
Error Envelope

{
  "success": false,
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded"
  },
  "meta": {
    "request_id": "req_abc123"
  }
}
Treat HTTP status as the control signal and the JSON body as debugging context. Validation, auth, route, plan-gate, rate-limit, and upstream errors require different client behavior. Use Errors for the retry model.

​
Empty Success Responses

Some historical requests return success: true with an empty data array. That can be a valid page for the requested symbol, route, cursor, or time window. Do not turn an empty page into synthetic rows. Store the route, query parameters, meta.count, meta.next_cursor, meta.request_id, and data-quality state, then decide whether the downstream job should continue, narrow the window, or mark the output incomplete.

​
Pagination

Historical routes can include meta.next_cursor. Keep request IDs per page, not just for the final result. A resumable job should store route family, route path, symbol, query parameters, cursor, request ID, output file, and data-quality decision. Do not widen pagination loops until a one-page request confirms the route family, response shape, and freshness gate.

​
Decimal And Field Semantics

Prices, sizes, funding rates, spreads, open interest, and liquidation values often need decimal-safe handling. Keep numeric-looking strings as strings unless the generated schema or client type states otherwise, then convert at the application edge with a decimal library when precision matters. Field meaning can depend on venue family. HIP-4 mark_price and mid_price represent implied probabilities in [0, 1], not USD prices. Spot symbols are pairs. HIP-3 symbols can include builder prefixes. Preserve venue family in stored records and logs.

​
Data-Quality Responses

Data-quality routes answer whether a downstream job should trust a market-data result. A degraded status, incident, latency issue, or coverage gap does not always mean every route is unusable. It means the client must compare the state to the job tolerance and record that decision. For backtests, alerts, exports, dashboards, and model features, store both the quality response and the downstream data request ID. Coverage routes such as /v1/data-quality/coverage/{exchange}/{symbol} can return resource-specific bodies without success, data, or meta; parse those from the REST reference instead of forcing the market-data envelope onto them.

​
Export Responses

Data Catalog exports return files and dashboard job state, not ordinary market-data JSON. Preserve the selected market, schema keys, UTC range, estimated size, credits, checkout state, delivery state, and data-rights decision with the export record. If the workflow needs programmatic market data, use REST, WebSocket, SDKs, CLI, MCP Server, or OpenAPI-backed routes.

​
Parser Checklist

1

Check HTTP status

Decide retry, fail-fast, auth repair, or support escalation from the status class.
2

Check body success

Handle success: false as an application error and preserve error.code.
3

Handle empty pages

Treat success: true plus empty data as a state to record, not as permission to fabricate records.
4

Log request ID

Store meta.request_id for envelope responses. For resource-specific bodies, store x-request-id or the client wrapper’s request handle when available.
5

Use the route schema

Parse data from the endpoint-specific OpenAPI schema, not from a nearby example.
6

Keep venue context

Persist venue family and symbol style beside records so downstream joins do not mix families.

​
Next Step

Use Example Responses for payload examples, Schemas for field categories, and Examples for copyable parser patterns.
Last modified on May 18, 2026