Installation
Install the package that matches your runtime.
REST usage
Call market-data routes with typed request options.
WebSocket usage
Subscribe, replay, and handle streaming messages.
Reconstruction
Maintain local books from snapshots and incremental updates.
Public SDK Packages
The SDKs are open source. Install from the registry, read the source on GitHub.
Use OpenAPI, REST, CLI, or MCP Server when the job belongs outside those package surfaces.
SDK Selection Checklist
Choose the integration surface before adding a package to an application.
The selection checklist 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 throughclient.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, preservemeta.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.