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

# SDKs

> Install 0xArchive SDKs and use typed clients for REST, WebSocket, and reconstruction workflows.

Use SDKs when you want typed requests, shared auth handling, WebSocket helpers, or order-book reconstruction in application code. Use REST directly for runtimes that do not have a package surface listed here.

<CardGroup cols={2}>
  <Card title="Installation" icon="download" href="/sdks/installation">
    Install the package that matches your runtime.
  </Card>

  <Card title="REST usage" icon="square-terminal" href="/sdks/rest-usage">
    Call market-data routes with typed request options.
  </Card>

  <Card title="WebSocket usage" icon="radio" href="/sdks/websocket-usage">
    Subscribe, replay, and handle streaming messages.
  </Card>

  <Card title="Reconstruction" icon="git-branch" href="/sdks/reconstruction">
    Maintain local books from snapshots and incremental updates.
  </Card>
</CardGroup>

<Tip>
  If a package or language surface is not listed here, use REST, WebSocket, CLI, or the OpenAPI contract directly.
</Tip>

## Public SDK Packages

| Runtime                 | Package          | Install shape                | Primary fit                                                                              |
| ----------------------- | ---------------- | ---------------------------- | ---------------------------------------------------------------------------------------- |
| TypeScript / JavaScript | `@0xarchive/sdk` | `npm install @0xarchive/sdk` | Typed app clients, WebSocket helpers, and reconstruction utilities                       |
| Python                  | `oxarchive`      | `pip install oxarchive`      | Notebooks, research scripts, data pipelines, async calls, and optional WebSocket support |
| Rust                    | `oxarchive`      | `cargo add oxarchive`        | Async services, typed market-data clients, and optional WebSocket feature support        |

Use OpenAPI, REST, CLI, or MCP Server when the job belongs outside those package surfaces.

## SDK Selection Packet

Choose the integration surface before adding a package to an application.

| Decision          | Use                                                                                                  |
| ----------------- | ---------------------------------------------------------------------------------------------------- |
| Runtime           | Pick the listed SDK only when it matches the application runtime and dependency policy               |
| Package truth     | Check the package registry page, repository README, and package manifest before pinning or upgrading |
| Route visibility  | Keep Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter namespaces visible in code                    |
| Auth              | Read `X-API-Key` from the environment or secret manager, not from browser-visible code               |
| Response handling | Preserve `success`, `data`, `error`, and `meta.request_id` on returned values or exceptions          |
| Streaming         | Use WebSocket helpers only when the workflow needs live updates, replay, or local state              |
| Reconstruction    | Use reconstruction utilities when order-book state must survive diffs, gaps, and resyncs             |
| Fallback          | Use REST, WebSocket, CLI, or OpenAPI codegen when the listed SDK surface does not fit                |

The selection packet should make a dependency review easy: why an SDK is needed, which public package was checked, which route families it touches, how request IDs are exposed, and what the fallback path is if the package surface is not the right fit.

## SDK Decision Rule

Use an SDK when your application benefits from typed calls, shared auth handling, connection helpers, or reconstruction utilities. Use REST directly when the runtime is small, the integration is a one-off job, or the SDK package for that runtime is not part of your dependency stack. Use OpenAPI when a coding agent or code generator needs to create a client in a language that is not covered by a first-party package.

The SDK docs mirror the rest of the portal: choose the venue family first, then use the route or helper for that family. TypeScript and Python package READMEs expose Spot helpers through `client.spot`; the Rust README exposes Spot under `client.hyperliquid.spot`. HIP-3 and HIP-4 stay under the Hyperliquid namespace. Keep those namespaces visible in code review so wrong-family symbol bugs are easy to catch.

## Production Use

Keep API keys in the environment or secret manager, preserve `meta.request_id`, and expose retry behavior to the caller. For WebSocket and reconstruction workflows, include a gap path and a resync path. Use the generated OpenAPI reference whenever exact route shape matters, and treat direct REST as a first-class integration path alongside SDK helpers.

## Generated-Client Rule

SDKs are application-code surfaces. Do not describe SDKs as coding agents or protocols. Use them when the developer wants typed code inside an application; use CLI, MCP Server, Skill, or OpenAPI for the other workflow shapes.