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

# Lighter API Quickstart

> Start using 0xArchive Lighter.xyz REST routes for order books, trades, funding, open interest, liquidations, candles, and freshness checks.

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.

<Steps>
  <Step title="Set your key">
    ```bash theme={"theme":"github-dark"}
    export OXARCHIVE_API_KEY="0xa_your_api_key"
    ```
  </Step>

  <Step title="Call a Lighter route">
    ```bash theme={"theme":"github-dark"}
    curl "https://api.0xarchive.io/v1/lighter/orderbook/BTC" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```
  </Step>

  <Step title="Check freshness">
    Use [Data quality](/data-quality) before long Lighter history or reconstruction jobs.
  </Step>
</Steps>

<CardGroup cols={2}>
  <Card title="Lighter REST" icon="zap" href="/rest-api/lighter">
    Lighter route family.
  </Card>

  <Card title="Lighter history" icon="history" href="/lighter-historical-data-api">
    Trades from August 2025, tick L2, and L3 history boundaries.
  </Card>

  <Card title="Reconstruction" icon="git-branch" href="/sdks/reconstruction">
    Local book maintenance patterns.
  </Card>
</CardGroup>

For the detailed Lighter history boundary, open [Lighter historical data API](/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

| Field               | Starter value                                                             |
| ------------------- | ------------------------------------------------------------------------- |
| Venue family        | Lighter.xyz                                                               |
| Namespace           | `/v1/lighter/*`                                                           |
| First route         | `/v1/lighter/orderbook/BTC`                                               |
| First fields to log | route, symbol, response timestamp, `meta.request_id`, status code         |
| Next branch         | trades, 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](/rest-api/lighter) for exact routes and generated schemas, including `/v1/lighter/liquidations/{symbol}` and `/v1/lighter/liquidations/{symbol}/volume`. Use [Historical market data](/guides/historical-market-data) when the job needs bounded windows. Use [WebSocket replay](/websocket/replay) when event ordering matters. Use [Data quality](/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.