> ## 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. # Responses > Parse 0xArchive success responses, error responses, pagination metadata, request IDs, decimal fields, and data-quality payloads. Response parsing should preserve the payload and the `meta` context that makes it usable later. Use [Example Responses](/response-examples) for schema-backed payload examples, [Schemas](/schemas) for shared field notes, and [OpenAPI](/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 ```json theme={"theme":"github-dark"} { "success": true, "data": [], "meta": { "count": 100, "next_cursor": "1704067200123_456789", "request_id": "550e8400-e29b-41d4-a716-446655440000" } } ``` | Field | Client behavior | | ------------------ | -------------------------------------------------------------------------- | | `success` | Treat `false` as an application-level failure even when a JSON body exists | | `data` | Parse according to the endpoint-specific schema | | `meta.count` | Use for returned item count, not necessarily total available records | | `meta.next_cursor` | Use for pagination when present | | `meta.request_id` | Log on success and failure for debugging and support | ## Response Handling Packet Use this packet before a client, agent, or parser stores response data. | Step | Required handling | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | HTTP status | Decide retry, auth repair, fail-fast behavior, or support escalation from the status class. | | `success` | Treat `success: false` as an application failure even when the HTTP response contains JSON. | | `data` | Parse from the endpoint-specific OpenAPI schema, not from a nearby example. | | `meta.request_id` | Store 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_cursor` | Keep cursor, route, symbol, query parameters, and request ID together for resumable jobs. | | Venue context | Persist venue family and symbol style beside records so joins do not mix Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter. | | Decimal fields | Keep numeric-looking market fields decimal-safe until the application boundary. | ## Error Envelope ```json theme={"theme":"github-dark"} { "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](/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 Decide retry, fail-fast, auth repair, or support escalation from the status class. Handle `success: false` as an application error and preserve `error.code`. Treat `success: true` plus empty `data` as a state to record, not as permission to fabricate records. Store `meta.request_id` for envelope responses. For resource-specific bodies, store `x-request-id` or the client wrapper's request handle when available. Parse `data` from the endpoint-specific OpenAPI schema, not from a nearby example. Persist venue family and symbol style beside records so downstream joins do not mix families. ## Next Step Use [Example Responses](/response-examples) for payload examples, [Schemas](/schemas) for field categories, and [Examples](/examples) for copyable parser patterns.