Hyperliquid API Rate Limits: What They Are and How to Work Within Them

Hyperliquid API rate limits are the first thing that bites a bot that was working fine in testing once it starts quoting in earnest. The limits are tighter than most traders expect, they operate at multiple layers simultaneously, and the error surface is different enough from CEX APIs that copy-paste logic from Binance or Bybit will fail in ways that are hard to debug under fire. Here is exactly what the limits are, why they exist, and how to build around them cleanly.

What Hyperliquid Actually Enforces

Hyperliquid imposes rate limits at two distinct layers: HTTP REST and WebSocket order placement.

On the REST side, the info endpoint (/info) is rate-limited per IP. In practice you can sustain roughly 1,200 requests per minute to info before seeing 429s, but burst behaviour matters — the bucket refills continuously, so a tight loop that fires 100 requests in under a second will drain the bucket and throttle you even if your per-minute average is well below the cap.

Order placement via REST (/exchange) is per-account (tied to the signing address), not per IP. The practical limit is around 10 order actions per second under normal conditions, where an "action" counts as one API call regardless of whether you send a single order or a batch. Cancel-all counts as one action. Modify counts as one. This is the number that matters for market makers.

WebSocket order placement shares the same per-account budget as REST — they are not separate pools. If your bot is simultaneously firing orders over HTTP and over the WebSocket connection, both streams draw from the same account-level bucket.

Order Batching: The Highest-Leverage Change You Can Make

If you are sending individual place-order calls, stop. Hyperliquid's exchange endpoint accepts bulk order arrays in a single action: you can batch up to 40 orders in one call, and it counts as one action against your rate limit. For a market maker posting on 5 markets with 2-sided quotes at 4 price levels, that is 40 orders in a single call instead of 40 calls.

The batching endpoint uses the same EIP-712 signing flow but wraps orders in an array under the orders key. Most bot frameworks treat this as an afterthought — wire it in from the start:

const action = {
  type: "order",
  orders: ordersArray,   // up to 40 Order objects
  grouping: "na",        // or "normalTpsl" for TP/SL grouping
};

Cancels are similarly batchable via the cancel action type, which accepts an array of { asset, oid } pairs. A cancel-all (cancelByCloid or the bulk cancel) is one action.

The practical rule: at 10 actions per second, batching 40 orders per action gives you theoretical throughput of 400 order operations per second from a single account. For most strategies that is more than sufficient. If you are hitting limits despite proper batching, the bottleneck is almost certainly in your quoting logic generating too many small amendments.

WebSocket Subscriptions and the post Channel

Hyperliquid's WebSocket has two distinct modes that are easy to conflate. The subscription channels (l2Book, trades, userFills, orderUpdates) are read-only and carry no rate limit worth worrying about — subscribe to everything you need. The post channel on the same WebSocket is where order placement goes, and it feeds the same account-level action budget as REST.

A few things to know operationally:

• One WebSocket per account is the practical limit. You can open multiple connections but they share the same action budget, and the exchange will start dropping connections if you stack too many.
• Heartbeat matters. Hyperliquid drops connections that miss the ping/pong cycle. Your reconnect logic must handle close events fast — a stale connection that silently stops receiving orderUpdates will cause your internal state to drift.
• Order update latency over WebSocket is meaningfully lower than polling REST for fill confirmation. Use userFills subscription for execution feedback; polling /info for fills is both slower and wasteful against the IP-level info budget.

For bots that need to maintain tight quotes, the recommended topology is: one WebSocket for inbound data (book, fills, position updates), one WebSocket for outbound order placement via the post channel. Keep them on the same process, handle reconnect atomically, and pause quoting while either connection is down.

Managing the 429: Detection and Failover

When you hit a rate limit, Hyperliquid returns HTTP 429 with a Retry-After header. The body is a plain-text error string — not a JSON envelope — so parsers that expect {"error": ...} will throw. Parse the raw body.

The fastest failover path:

1. Detect 429 at the HTTP client level, not in business logic. A thin middleware wrapper that catches 429 and sets a backoff flag prevents order storms from compounding the problem.
2. Stop all outbound actions immediately. Do not retry the failed request automatically — retry storms are how you get temporarily banned at the IP level.
3. Honor Retry-After exactly. It is typically 1–5 seconds. Sleep that duration, then resume with a reduced action rate (halve your target throughput and ramp back up over 30 seconds).
4. Alert immediately. A 429 in production means your rate math is wrong somewhere. It should never be a silent catch.

For market-making bots specifically — like the ones we ship for Hyperliquid perp strategies — the right design is a token-bucket at the action scheduler level with a ceiling of 8 actions per second (leaving 20% headroom). The scheduler drains the bucket before dispatching; if the bucket is empty, the next quote cycle waits. This is cleaner than catching 429s reactively and keeps your fill latency stable.

Account Tiers and Higher Limits

Hyperliquid does offer higher rate limits for accounts with significant volume. The tier thresholds change periodically and are not publicly documented with hard numbers, but accounts generating meaningful maker volume (in the range of tens of millions notional per 30-day window) are typically eligible for elevated limits through direct contact with the team. If you are at the point where 10 actions per second is a genuine constraint — not a design problem — that conversation is worth having.

For most systematic strategies, including multi-market makers running a dozen perp pairs, the standard limits are not the ceiling. Sloppy action patterns are. Audit your cancel rate: if you are cancelling more than you are filling, your quoting logic is probably emitting too many amendments. A well-designed quoting engine on Hyperliquid should comfortably run within budget at 5–7 actions per second with batching.

State Reconciliation After a Limit Event

The dangerous moment is not the 429 itself — it is the 30 seconds after, when your bot resumes but its internal order book is stale. Orders you tried to place may have landed (or not). Amendments you fired during the spike may have partially succeeded.

After any rate-limit event, before resuming normal quoting:

• Fetch open orders via /info with type: "openOrders" for the account
• Reconcile against your internal state
• Cancel any orders whose state is ambiguous
• Rebuild quotes from a clean slate

This reconciliation step is often skipped in quick implementations and is the source of ghost orders and doubled exposure. The few hundred milliseconds it adds is negligible compared to the risk of running on a corrupted internal state. We cover this pattern in more detail in the context of our cross-venue arbitrage work.

---

If you are building a Hyperliquid bot and want rate-limit-aware architecture from the start rather than retrofitted as a hotfix, reach out — we scope and ship these systems in production.