Hyperliquid API Rate Limits Explained
Hyperliquid applies both IP-based request weights and address-based action limits, so production clients need batching, caching, WebSockets, and deliberate retry logic rather than brute-force polling.
Hyperliquid API capacity is governed by more than one counter. Current documentation specifies a weighted REST budget per IP, connection and message limits for WebSockets, and an address-based action allowance related to cumulative trading volume. These limits are designed so information access and trading actions can scale without one client monopolizing infrastructure.
IP-based REST weights
At review time, documented REST traffic shares an aggregate 1,200 weight per minute per IP. Exchange requests and Info requests carry different weights, and some data-heavy Info responses add weight based on the number of returned items.
The implication is simple: “one HTTP request” is not one unit of cost.
Address-based actions
Trading-action capacity is also linked to the account. Each address begins with a request buffer, then cumulative executed volume expands the allowance. Cancels receive additional room so an account that reaches its normal action limit can still reduce risk.
Subaccounts are treated separately for this purpose according to current docs.
WebSocket limits
Current documentation also caps connection creation, simultaneous connections, subscriptions, and messages. Opening a new socket for every symbol or reconnecting in a tight loop is an anti-pattern.
Multiplex subscriptions across stable long-lived connections and implement exponential backoff.
Batching
Batched orders can reduce IP-weight cost, while address-based accounting can still count the underlying actions individually. Batching therefore improves transport efficiency without making action-level limits disappear.
Choose batch size based on strategy semantics as well as rate limits. Combining unrelated risk decisions into a giant batch can make failure handling harder.
Production design
Cache static metadata, subscribe to streams for rapidly changing state, poll only what cannot be streamed, and instrument remaining request budget. A rate-limit response should trigger controlled degradation, not an immediate retry storm.
When risk is high, cancellation capacity should be preserved before informational convenience.