Skip to main content
Lighter is a separate top-level venue family. Use /v1/lighter/* routes for Lighter instruments, order books, trades, funding, open interest, liquidations, and L3 depth.
1

Set your key

export OXARCHIVE_API_KEY="0xa_your_api_key"
2

Call a Lighter route

curl "https://api.0xarchive.io/v1/lighter/orderbook/BTC" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
3

Check freshness

Use Data quality before long Lighter history or reconstruction jobs.

Lighter REST

Lighter route family.

Lighter history

Trades from August 2025, tick L2, and L3 history boundaries.

Reconstruction

Local book maintenance patterns.
For the detailed Lighter history boundary, open Lighter historical data API.

​
What This Confirms

The first Lighter request confirms that the key, base URL, Lighter namespace, symbol, and response envelope are working together. It does not confirm that every Lighter data family, time window, L3 route, or replay job is available to the same key.

​
Lighter Request Checklist

FieldStarter value
Venue familyLighter.xyz
Namespace/v1/lighter/*
First route/v1/lighter/orderbook/BTC
First fields to logroute, symbol, response timestamp, meta.request_id, status code
Next branchtrades, candles, funding, OI, liquidations, L3, replay, or reconstruction
Keep this checklist separate from Hyperliquid core, Spot, HIP-3, and HIP-4 checklists. A generic BTC string is not enough context for logs or generated clients.

​
Next Branches

Use Lighter REST for exact routes and generated schemas, including /v1/lighter/liquidations/{symbol} and /v1/lighter/liquidations/{symbol}/volume. Use Historical market data when the job needs bounded windows. Use WebSocket replay when event ordering matters. Use Data quality before an output feeds a backtest, alert, export, or model.

​
Common Mistakes

Do not route Lighter symbols through Hyperliquid examples. Do not assume Lighter L3 and Hyperliquid L4 are the same primitive. Keep venue family in logs, storage, and generated code so later joins or comparisons can distinguish sources.

​
Buyer Fit

Use this path when the product specifically needs Lighter data rather than a generic crypto price. The first route should confirm that Lighter is the correct venue family, then the implementation can switch to trades, candles, funding, open interest, liquidations, L3, replay, or SDK reconstruction depending on the job.

​
L2 Versus L3 Decision

Use L2 order-book routes when aggregated price-level depth answers the question. Use L3 when the workflow needs order-level state, queue behavior, or reconstruction-oriented history. Treat L3 as a different data family in storage, tests, and exports; do not merge it into generic order-book output without labeling the depth level.

​
Expansion Rule

Keep the first working request as a fixture. When the client expands, compare every new route to that fixture for auth, envelope shape, symbol handling, and request-ID logging. That makes Lighter-specific regressions easier to catch. If the next workflow is L3 or replay, add gap handling before using the result in production.
Last modified on July 4, 2026