Skip to main content
Generated endpoint pages contain the route-specific schemas. This page covers the shared response model, common market-data payload shapes, and the fields most clients should handle consistently. Use Responses when you need parser behavior, Example responses when you need payload examples, Examples when you need copyable request code, and Export schemas when the user is choosing Parquet file datasets.

​
Schema Source

OpenAPI, Endpoint Reference, and Operation Schemas define REST requests and responses. Schema pages are refreshed from openapi.json so builders can browse component schemas, operation schemas, and route families without treating examples as complete coverage. Examples help with parser expectations, but client types should still come from the schema pages. 
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "0xArchive response envelope",
  "type": "object",
  "required": ["success"],
  "properties": {
    "success": {
      "type": "boolean",
      "description": "Whether the request succeeded."
    },
    "data": {
      "description": "Route-specific payload documented by the generated operation schema."
    },
    "meta": {
      "type": "object",
      "properties": {
        "count": {
          "type": "integer"
        },
        "next_cursor": {
          "type": "string"
        },
        "request_id": {
          "type": "string"
        }
      },
      "additionalProperties": true
    },
    "error": {
      "type": "object",
      "properties": {
        "code": {
          "type": "string"
        },
        "message": {
          "type": "string"
        }
      },
      "additionalProperties": true
    }
  },
  "additionalProperties": true
}

Component schemas

Browse every generated OpenAPI component schema.

Operation schemas

Open route-level request and response JSON Schema pages.

Hyperliquid core schemas

Review generated Hyperliquid core operation contracts.

Hyperliquid Spot schemas

Review generated Spot operation contracts.

HIP-3 schemas

Review generated HIP-3 operation contracts.

HIP-4 schemas

Review generated HIP-4 operation contracts.

Lighter schemas

Review generated Lighter operation contracts.

Data quality schemas

Review generated status, coverage, and quality contracts.

Export manifest schemas

Browse generator-backed Data Catalog export manifest schemas.

WebSocket messages

See the generated bridge to the current WebSocket command inventory.

​
Envelope

​
success
boolean
true for successful responses. Error responses use success: false.
​
data
object | array
Route payload. Historical list routes usually return arrays, while market-state routes often return objects.
​
meta.count
integer
Number of returned items.
​
meta.next_cursor
string
Cursor for the next page when a paginated historical route has more results.
​
meta.request_id
string
Identifier to log for debugging and support.

​
Schema Families

FamilySchema intentExample routes
Instruments and pairsMarket discovery and symbol metadata/v1/hyperliquid/instruments, /v1/hyperliquid/spot/pairs, /v1/lighter/instruments
Order booksBids, asks, timestamps, spread, depth, and route-specific order-book records/orderbook/{symbol}, L3, L4, and history routes
TradesSide, price, size, timestamp, and source-specific fields/trades/{symbol} and recent trade routes
CandlesOHLC-style time buckets/candles/{symbol}
Funding and open interestTimestamped funding, premium, mark/mid context, and OI values/v1/hyperliquid/funding/{symbol}, /v1/hyperliquid/openinterest/{symbol}, and venue-specific equivalents
Liquidations and ordersLiquidation events, order history, flow, and TPSL recordsLiquidation and order routes where available
Spot TWAPHyperliquid Spot TWAP records/v1/hyperliquid/spot/twap/{symbol}
Data qualityCoverage, status, incidents, latency, and SLA records/v1/data-quality/*
SIWE verificationSIWE challenge, signup, key, revoke, and subscribe responses/v1/auth/web3/challenge, /v1/web3/signup, /v1/web3/keys
Export datasetsParquet schema keys, coverage keys, rough columns, pricing units, and file-delivery metadataData Catalog export schemas

​
Client Schema Checklist

Use this checklist before generating types, warehouse tables, or agent parser instructions.
Schema decisionPublic rule
Route-specific typeStart from Endpoint reference, OpenAPI, or route-level pages in Operation schemas.
Shared envelopeApply success, data, meta.count, meta.next_cursor, and meta.request_id handling consistently.
Empty result stateModel success: true with an empty array separately from transport failure, auth failure, and missing-route errors.
Venue-specific fieldsKeep Spot pairs, HIP-3 prefixes, HIP-4 outcome identifiers, and Lighter symbols distinct.
Decimal valuesTreat prices, sizes, rates, spreads, open interest, and probability-like fields as decimal-sensitive.
High-depth booksKeep L2 snapshots, L3 individual orders, L4 book state, and L4 order events as separate schemas.
Export filesUse Export schemas; do not reuse JSON response schemas as Parquet table contracts without source metadata.

​
Market Fields

Order-book payloads include bids, asks, timestamps, mid price, spread, and venue-specific depth fields. L3 and L4 records should be stored separately from ordinary L2 snapshots.
Trade payloads include side, price, size, timestamp, and route-specific fields such as wallet/account identifiers where the source supports them.
Funding and OI payloads include timestamped rate, premium, mark, mid, and open-interest fields depending on venue family.
HIP-4 mark_price and mid_price represent implied probability in [0, 1], not USD.
Coverage, latency, freshness, incident, and SLA payloads are trust signals. A client should compare them to the job tolerance before downstream systems use market data.

​
Schema Use In Clients

Generated endpoint pages are the source for route-specific schemas. Use this page for shared behavior that should appear in every client: success handling, pagination metadata, request IDs, timestamp parsing, and error propagation. Keep numeric-looking market fields as strings unless the route schema or generated type states otherwise. Prices, sizes, spreads, rates, and open-interest values often need decimal-safe handling. Convert them at the application edge with a decimal library instead of relying on floating-point defaults in strategy, accounting, or model code.

​
Export Schemas Versus API Schemas

API schemas describe JSON responses from REST and WebSocket surfaces. Export schemas describe file-style Parquet datasets from the Data Catalog. Keep those models separate. An API order-book response, an L2 export, an L3 export, an L4 order-book export, and an order-events export can all represent order-book-adjacent data, but they should not share one warehouse schema without preserving source and schema key. Use Export schemas for schema keys such as l2_orderbook, l3_orderbook, l4_orderbook, l4_orders, trades, funding, oi, and liquidations.

​
Venue-Specific Meaning

The same field name can mean different things by venue family. HIP-4 prices are probabilities, not USD prices. Spot symbols are pairs such as HYPE-USDC. HIP-3 symbols can include a builder prefix such as km:US500. Lighter routes live under their own namespace. Preserve the venue family in stored records so downstream joins do not treat unrelated symbols as the same instrument.

​
Examples And Responses

Examples show route family, auth, request IDs, bounded scope, and schema-backed payload shapes. Client code should still parse from the schema pages. Response handling should check HTTP status, success, error.code, pagination metadata, and meta.request_id.

REST API

Open endpoint-specific schemas.

Errors

Handle error responses and request IDs.

Responses

Parse envelopes, pagination, errors, and decimal-sensitive fields.

Example responses

Review schema-backed JSON examples before writing parsers or tests.

Examples

Copy bounded request, parser, WebSocket, and agent examples.

Export schemas

Choose Parquet export datasets and preserve schema keys.
Last modified on June 28, 2026