The Hyperliquid API: Orders, WebSockets and Rate Limits

Hyperliquid runs a fully on-chain CLOB (central limit order book) on its own L1, which means every order, cancel, and fill is a signed transaction — not a permissioned REST call to a centralised exchange. That distinction shapes every part of the integration: authentication, latency strategy, and error handling all differ from what you might expect coming from a CEX background.

The Two Core Endpoints

The API splits neatly into two namespaces, both accessed via POST to https://api.hyperliquid.xyz/:

/info — read-only queries. No signing required. Use it to pull:

• Mid prices, mark prices, and 24-hour statistics per asset
• Full L2 order book snapshots (l2Book)
• Open positions and margin state for a given address
• Funding rate history and predicted next-period funding
• Trade history and fill records

/exchange — state-mutating actions. Every request must carry a valid EIP-712 signature produced by the agent wallet. Actions include placing orders (order), cancelling by client order ID or exchange OID (cancel, cancelByClid), modifying in-flight orders (modify), and adjusting leverage or cross/isolated margin settings.

Batching is worth understanding early. A single order action can carry up to 100 order objects inside its orders array. Grouping related legs of a spread or a delta-neutral entry into one signed payload cuts round-trips and keeps the legs as close to atomic as the chain allows.

Signing and Agent Wallets

Hyperliquid uses EIP-712 typed-data signing rather than API keys. Your signing key is an Ethereum private key, and the chain verifies the recovered address against the account's approved agent list.

The recommended pattern for bots is to register a dedicated agent wallet: a hot key with limited permissions (trade only, no withdrawals) that signs on behalf of the main account. This is the practical kill-switch equivalent for on-chain systems — revoke the agent, and the bot can no longer submit orders, regardless of whether your server is compromised.

The domain separator is fixed to the Hyperliquid mainnet chain ID. Every action type has its own EIP-712 struct (e.g., Order, Cancel, ModifyOrder), and the nonce is a monotonically increasing integer scoped to the agent address. Replay protection is enforced at the L1 level.

For testing, the testnet endpoint at https://api.hyperliquid-testnet.xyz/ accepts the same signing flow but with testnet funds, so you can validate order routing, fill simulation, and error-path handling before touching real capital. See our hyperliquid market maker case study for how we stress-tested signing throughput at 50 RPS against the testnet before going live.

WebSocket Subscriptions

Persistent state comes from wss://api.hyperliquid.xyz/ws. After the connection is established, you subscribe by sending a JSON frame with a method: "subscribe" key and a subscription object. The most useful subscription types for bot builders:

• l2Book — streaming order book diffs for a specific asset. The initial snapshot is followed by delta updates; you maintain a local book and apply each diff in sequence. Useful for inventory-skew market making where your quote depends on the live mid.
• trades — public trade tape for an asset. Good for momentum signals and detecting large prints that justify pulling quotes.
• userFills — private fill events for your agent address. Lets you reconcile inventory in near-real time without polling /info.
• userEvents — broader account events including liquidation warnings and funding settlements.
• activeAssetCtx — per-asset context updates including open interest and the next predicted funding rate. Critical for strategies that express a view on funding, where the cost of carry can flip your edge.

Heartbeat frames ({"method":"ping"}) must be sent at least every 30 seconds or the server will close the connection. Build automatic reconnect logic with exponential backoff; WebSocket drops during volatile periods are normal and your bot must resume quoting without requiring a restart.

Rate Limits and Practical Throughput

The /info endpoint is generous: roughly 1,200 requests per minute per IP for most query types. Order book polling is unnecessary if you have a WebSocket book subscription, but /info is useful for the initial state snapshot on bot startup.

The /exchange endpoint is tighter. The current documented limit is around 100 order actions per 10 seconds per account, with burst headroom for short spikes. Exceeding it returns a 429 with a Retry-After header. For high-frequency market makers, the practical ceiling means you should:

• Batch order placements into single requests wherever possible
• Use modify rather than cancel-then-replace to reduce action count
• Implement a local rate-limit token bucket before the HTTP call, so you never reach the server-side limit in the first place

Unlike Solana — where priority fees and Jito bundle tips are the primary latency levers — Hyperliquid's L1 processes actions in the order they arrive at the validator. Co-location near the validator cluster is therefore the main throughput advantage for latency-sensitive strategies.

---

Building on Hyperliquid is genuinely different from CEX or EVM DeFi integrations, and the details above only cover the core surface. If you want a production bot with proper signing infrastructure, reconnect logic, kill-switches, and risk controls already wired in, start a project with us — or explore our full range of trading-bot services to see what we ship.