About this guide: I'm Lawrence, the writer behind supa.is. Between February and May 2026 I've published 150+ articles on supa.is across crypto and brokerage tooling — including 30+ Hyperliquid-specific guides (recent examples: Hyperliquid Python SDK Tutorial, Hyperliquid API Error Responses, Hyperliquid API Agent Wallet Setup). The most-repeated reader question across that Hyperliquid archive is exactly how to avoid API throttling, which is why I'm publishing this standardized guide instead of answering one-off.
Why Hyperliquid Enforces API Rate Limits
Hyperliquid is not a traditional centralized exchange with redundant server clusters absorbing traffic spikes. It is a high-performance L1 blockchain with a custom matching engine, so its API architecture is tightly coupled with on-chain state.
Every order placed via the API interacts with the Hyperliquid L1. If a single user floods the API, it can cause latency spikes for other users, increase state pressure, and create an unfair execution advantage.
Rate limits are the primary defense against that behavior. They ensure that API consumers, whether retail traders running a simple script or institutional players running high-frequency strategies, share the network fairly.
Hyperliquid API Rate Limits: The Numbers
Hyperliquid's rate limits are applied at the IP address level. This means each unique IP address has its own quota. If you are running multiple bots from the same server, you should consider distributing the load across your workloads.
According to the official Hyperliquid documentation, the rate limits are structured around a weighted sliding window mechanism. Here is the breakdown of the current limits as of 2026-08:
1. Global Request Rate Limit
Hyperliquid caps you at 1200 aggregated weight per minute per IP address, as of 2026-08. This applies to everything: order placement, cancellations, and data queries. Exceed it, and you'll get a 429 Too Many Requests error with a Retry-After header telling you how long to wait.
The weight of a request varies depending on the endpoint and the size of the data returned. Unbatched actions have a weight of 1, while batched order requests have a weight of 1 + floor(batch_length / 40). For example, a batched order of 79 orders has a weight of 2.
2. Order Placement Rate Limit
Placing orders is computationally expensive, so Hyperliquid enforces a stricter weight system. If you're running a high-frequency market-making strategy, you'll need to budget your order weight carefully within the 1200/minute global cap.
3. Data Query Rate Limit
Fetching the order book, recent trades, or positions is less taxing, but still capped. It's easy to exceed this in a tight polling loop. A script checking the order book every 100ms burns 10 req/s; run 3 of those on the same IP and you've already hit your global 30 req/s cap, leaving zero room for actual trades.
4. Endpoint-Specific Weight Penalties
Not all data requests are created equal. The API assigns heavier weights to specific endpoints to discourage abuse of expensive data:
* Weight 2: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, and exchangeStatus.
userRole endpoint.
* Weight 40: All explorer API requests.
5. Response-Size Based Weight Penalties
Hyperliquid dynamically adjusts the weight based on the volume of data returned. If an endpoint returns a large array, your rate limit quota burns faster.
* Weight +1 per 20 items returned: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, and validatorStats.
candleSnapshot endpoint.
* Block-based limits: The blockList endpoint is limited to 1 request per block. Older blocks that haven't been recently queried are weighted more heavily. For large batch requests of historical block data, you should use the S3 bucket instead of the API.
6. WebSocket Limits
WebSockets are the preferred method for real-time data, but they are strictly capped to prevent connection flooding:
* Maximum of 10 WebSocket connections per IP.
* Maximum of 30 new WebSocket connections per minute. * Maximum of 1000 WebSocket subscriptions total. * Maximum of 10 unique users across user-specific WebSocket subscriptions. * Maximum of 2000 messages sent to Hyperliquid per minute across all WebSocket connections. * Maximum of 100 simultaneous inflight POST messages across all WebSocket connections.7. EVM JSON-RPC Limits
If you are querying the EVM side of Hyperliquid via rpc.hyperliquid.xyz/evm, you are limited to 100 requests per minute. Other JSON-RPC providers have more sophisticated rate limiting and archive node functionality, so for heavy EVM querying, consider using a dedicated RPC provider.
Hyperliquid User Limits
Beyond rate limits, Hyperliquid also enforces user limits. These are not about how fast you can make requests, but rather *what* you can do within a single request or a short timeframe.
1. Maximum Orders Per Request
You can batch orders into a single API call, but Hyperliquid caps it at 10 orders per batch. Submit more, and the whole batch gets rejected.
2. Maximum Open Orders
You can only have 100 open orders at any given time across all markets. This prevents users from hoarding order book space. If you're a market maker, you'll need to aggressively cancel stale orders before placing new ones, or your 101st order will fail.
3. Position Limits
While not strictly an API limit, Hyperliquid enforces position limits on certain markets. These are usually tied to the funding rate and the overall risk exposure of the market. If you try to open a position that exceeds the maximum allowed size for that market, the order will be rejected.
How to Avoid Hitting Rate Limits
These four fixes cover most throttling I see in reader questions. None of them require changing your strategy.
Like what you're reading? Try it yourself — this link supports ChartedTrader at no cost to you.
Sign up on Hyperliquid →1. Use Exponential Backoff
When you receive a 429 Too Many Requests error, do not immediately retry. Instead, implement an exponential backoff strategy. Start by waiting 1 second, then 2 seconds, then 4 seconds, and so on, up to a maximum of 30 seconds. This prevents your bot from continuously hammering the API and getting permanently banned.
2. Batch Your Requests
If you need to place multiple orders, batch them into a single request — up to 10 orders per batch, per the user limit above. Five orders across three markets becomes one call instead of five, and the batch weight formula keeps the cost predictable.
3. Use WebSockets for Real-Time Data
Polling burns quota fast — the 100ms order-book example above shows how quickly. Subscribe to market data over WebSocket instead, and reserve your REST budget for order placement and the occasional state check.
4. Monitor Your Usage
Implement a local counter in your bot to track how many requests you are making per second. If you see your request rate approaching 90% of the limit, slow down your bot. It's better to be proactive than to get throttled.
What Happens When You Exceed Limits?
When you exceed Hyperliquid's rate limits, the API will return a 429 Too Many Requests status code. The response body will contain a JSON object with an error message and a Retry-After field.
{
"status": "error",
"message": "Rate limit exceeded. Please wait before making another request.",
"retry_after": 5
}
The retry_after field indicates the number of seconds you must wait before making another request. If you ignore this and continue to make requests, your API key may be temporarily suspended. In severe cases, repeated abuse of the API can lead to a permanent ban.
Planning Your Bot's Request Budget
The numbers above become practical when you translate them into a per-second budget. With 1200 weight per minute, your average ceiling is 20 weighted requests per second. A market-making bot that refreshes quotes on 10 symbols via l2Book (weight 2 each) spends 20 weight per refresh cycle, so two full cycles per second already consume the entire budget before a single order is placed.
The 100-open-order cap compounds this: a 20-symbol book with 5 quotes per side needs 200 resting orders, which is double the allowance. The workable pattern is to keep resting depth shallow (2-3 quotes per side on the core symbols) and reserve the remaining order slots for the rest of the book, cancelling and replacing rather than stacking.
One honest limitation: the documentation describes the weight model but does not publish per-endpoint weight tables for every action, so treat the weights listed above as the documented baseline and verify behavior with your own load testing before going live.
Troubleshooting Common API Issues
Three failure modes come up more than any others in the reader questions I get.
Issue: Orders are not being filled
Check if your price is too far from the market (slippage), if the market lacks liquidity, or if you're actually hitting rate limits and getting rejected.
Issue: API key is being rejected
Double-check your key and secret. If you've set up an IP whitelist, ensure your server's IP is on it, and verify the key has the necessary trade permissions.
Issue: High latency
First rule out your own network, then check whether you're being throttled — queued requests after a 429 inflate measured latency and look exactly like a slow connection.
Final Thoughts
Respecting these limits is what keeps a bot alive in a high-frequency environment. Backoff, batching, and a local usage counter do most of the work.
If you are just getting started with Hyperliquid, make sure to sign up using our referral link to get a 4% fee discount on your trades. And if you need help with API key setup, check out our Hyperliquid API Agent Wallet Setup guide. The 4% referral discount applies to the first $25M of eligible volume; Vault and sub-account activity is excluded.
Risk Warning: Crypto trading involves substantial risk of loss. Never invest more than you can afford to lose. This is not financial advice.
FAQ
What happens if I exceed Hyperliquid's rate limits?
If you exceed the rate limits, your requests will be rejected with a 429 Too Many Requests error. You must wait for the specified Retry-After time before making another request. Repeated abuse can lead to temporary or permanent suspension of your API key.
Can I increase my rate limits on Hyperliquid?
Currently, Hyperliquid does not offer a way to increase rate limits for individual users. If you need higher throughput, you should consider splitting your strategy across multiple API keys.
How many open orders can I have on Hyperliquid?
Hyperliquid limits users to a maximum of 100 open orders at any given time. This applies across all markets.
Does Hyperliquid have an IP whitelist for API keys?
Yes, Hyperliquid allows you to set up an IP whitelist for your API keys. This adds an extra layer of security by ensuring that only requests from specific IP addresses can use your API key.
Why does Hyperliquid enforce rate limits?
Hyperliquid enforces rate limits to maintain system stability, prevent network congestion, and ensure fair access for all users. Without rate limits, a single user could flood the network with requests, causing latency spikes and degrading the experience for everyone else.