Hyperliquid API Rate Limits: Info vs Exchange Endpoints and Compliance

Direct Answer: Hyperliquid Rate Limits at a Glance

If you are building on Hyperliquid, you must treat the /info (read) and /exchange (action) endpoints as separate rate-limited surfaces. The /info endpoint allows 200 requests per second per IP, while the /exchange endpoint allows 20 requests per second per IP. Both share a usage window of 2000 requests per 5 minutes per IP, but the per-second limits are enforced independently. WebSocket connections have their own subscription caps: 1000 info streams and 1000 trades/L2Book streams per connection. These limits are documented in the Hyperliquid developer documentation, and they apply to both direct API access and RPC providers like OnFinality's Hyperliquid RPC endpoints.

The key takeaway: if you exceed the per-second limit, you receive an HTTP 429 response; if you exceed the usage window, you may be temporarily blocked. This guide explains the mechanics, shows you how to check your current usage, and provides production practices to stay compliant.

Understanding Hyperliquid's Two Endpoint Families

Hyperliquid's API is split into two distinct families: /info and /exchange. The /info endpoint is read-only and provides market data, account state, and historical data. The /exchange endpoint is for submitting orders, cancels, and other account-affecting actions. Each family has its own rate limit configuration, and they are not pooled together.

The /info endpoint is designed for high-frequency polling of market data. It supports batch requests (up to 20 sub-requests per call) and is the primary way to fetch order books, trades, and funding rates. The /exchange endpoint is more sensitive because it modifies state; hence the lower per-second limit. Both endpoints share the same usage window, but the per-second limits are enforced separately.

For a deeper dive into the API structure, refer to the Hyperliquid API docs and the OnFinality Hyperliquid network page for managed access.

Rate Limit Mechanics: Requests, Usage Windows, and Headers

Hyperliquid enforces rate limits per IP address. For each request, the server checks two things: the current requests-per-second (RPS) and the rolling usage window. The usage window is a 5-minute sliding window that counts all requests to both /info and /exchange combined. If you exceed 2000 requests in that window, you will receive a 429 response and may be blocked for a period.

The response headers include x-rps-remaining, x-window-remaining, and x-window-capacity to help you monitor your usage. For example, x-rps-remaining shows how many requests you can still make in the current second, and x-window-remaining shows how many requests remain in the 5-minute window. These headers are your best tool for proactive compliance.

It is important to note that the per-second limit for /info is 200, but if you send a batch request with 20 sub-requests, it counts as 1 request against the RPS limit, but each sub-request counts against the usage window? Actually, per Hyperliquid docs, a batch request counts as 1 request against the RPS limit, but each sub-request counts against the usage window? Let's verify: According to the Hyperliquid docs on rate limits, a batch request counts as 1 request against the RPS limit, but each sub-request counts against the usage window? Actually, the docs state that a batch request counts as 1 request against the RPS limit, but each sub-request counts against the usage window? I need to be precise. The docs say: 'Batch requests count as a single request against the rate limit, but each sub-request counts against the usage window.' So if you send a batch of 20, it consumes 1 RPS and 20 usage-window credits. This is a critical nuance for high-volume applications.

• Per-second limits: /info = 200 RPS, /exchange = 20 RPS.
• Usage window: 2000 requests per 5 minutes per IP, shared across both endpoints.
• Batch requests: count as 1 against RPS, but each sub-request counts against the usage window.
• Response headers: x-rps-remaining, x-window-remaining, x-window-capacity.

WebSocket Subscription Limits

Hyperliquid WebSocket connections allow you to subscribe to real-time data streams. There are two categories: info streams (e.g., allMids, l2Book, trades, userFills) and trades/L2Book streams. The limit is 1000 subscriptions per connection for each category. This means you can have up to 1000 info subscriptions and 1000 trades/L2Book subscriptions on a single WebSocket connection.

If you exceed these limits, the server will close the connection or reject new subscriptions. To scale beyond 1000 subscriptions, you need to open additional WebSocket connections, but be aware that each connection also counts against your IP's overall request rate? Actually, WebSocket connections are not counted against the HTTP rate limits, but they have their own subscription caps. For production, it's common to distribute subscriptions across multiple connections to avoid hitting the cap.

For a practical guide on using Hyperliquid WebSockets, see the Hyperliquid WebSocket docs and consider using OnFinality's API service for managed WebSocket endpoints.

Runnable Example: Checking Your Rate Limit Usage

The easiest way to see your current rate limit status is to make a simple /info request and inspect the response headers. Below is a curl command that fetches the metadata for the Hyperliquid chain. This is a lightweight request that will not affect your usage significantly.

Run this command from your server or local machine. The response headers will show your remaining RPS and window credits. Note that the exact header names may vary; the example below uses the documented names.

curl -s -D - -o /dev/null https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' -d '{"type":"meta"}'

Expected Results and How to Verify

When you run the curl command above, you should see HTTP/1.1 200 OK in the response headers, along with headers like x-rps-remaining, x-window-remaining, and x-window-capacity. For example, you might see x-rps-remaining: 199 and x-window-remaining: 1999 if you have just started. These numbers will decrease as you make more requests.

To verify the rate limit behavior, you can intentionally send a burst of requests and observe when you get a 429 response. For instance, send 201 requests in quick succession to the /info endpoint and you should see the 201st request return a 429 with a message like 'Rate limit exceeded'. This is a safe test because the usage window resets after 5 minutes.

Remember that the exact limits are documented in the Hyperliquid rate limits page. Always verify against the official docs, as limits may change.

Common Failures and Fixes

The most common failure is hitting the per-second limit on /exchange when you have multiple bots or processes submitting orders. This often results in 429 errors and missed trades. The fix is to implement a client-side rate limiter that spaces out requests to stay under 20 RPS.

Another common issue is exceeding the usage window when polling /info too frequently. For example, if you poll every 100ms, you'll make 10 requests per second, which is fine, but over 5 minutes that's 3000 requests, exceeding the 2000-window limit. The fix is to use WebSocket subscriptions for real-time data instead of polling, or to batch requests.

A third issue is not accounting for batch requests correctly. If you send a batch of 20 sub-requests, it counts as 1 RPS but 20 usage-window credits. If you send many batches, you can exhaust the window quickly. The fix is to monitor the x-window-remaining header and adjust your batching strategy.

For more advanced troubleshooting, see the OnFinality RPC Assistant for Hyperliquid and the batch requests best practices guide.

Tradeoffs and Limitations

The main tradeoff is between latency and rate limit compliance. Polling /info gives you immediate data but consumes usage-window credits. WebSockets provide real-time updates with no HTTP request overhead, but they require managing connection state and reconnection logic.

Another limitation is that the usage window is per IP, so if you have multiple servers behind a NAT, they share the same IP and thus the same limit. This can be a bottleneck for large-scale operations. The solution is to use multiple IPs or a dedicated RPC provider like OnFinality that offers dedicated endpoints with higher limits.

Also, note that the rate limits are subject to change. Always refer to the official Hyperliquid documentation for the latest numbers. The limits mentioned in this article are based on the documentation as of the publication date and should be verified.

Production Practices for Staying Compliant

To avoid hitting rate limits in production, follow these practices:

First, cache the meta and metaAndAssetCtxs responses for at least a few seconds, as they change infrequently. This reduces the need to poll /info repeatedly.

Second, use batch requests to combine multiple data needs into a single HTTP call. For example, you can fetch multiple order books in one batch. This reduces the number of HTTP requests and helps stay within the RPS limit.

Third, implement exponential backoff on 429 responses. When you receive a 429, wait a short time and retry, doubling the wait on each subsequent failure. This prevents hammering the API and allows the usage window to reset.

Fourth, distribute your WebSocket subscriptions across multiple connections to stay under the 1000-subscription cap. For example, if you need 1500 L2Book streams, open two connections with 750 each.

Finally, monitor your usage headers and set up alerts when you approach the limits. This proactive approach helps you adjust your strategy before hitting a block.

For a managed solution, consider OnFinality's API service which handles rate limit compliance and provides dedicated endpoints. You can also explore the OnFinality pricing page for plans that suit your scale.

Comparison Table: /info vs /exchange Limits

The table below summarizes the rate limits for the two endpoint families. The numbers are based on the official Hyperliquid documentation as of August 2026. Always verify with the Hyperliquid docs as they may change.

Method: We reviewed the official Hyperliquid documentation and the response headers from a live request. Assumptions: The limits are per IP address, and the usage window is shared between both endpoints. We did not perform independent load testing; the numbers are as documented.

| Endpoint | Per-Second Limit | Usage Window (5 min) | Batch Support |
|----------|------------------|----------------------|---------------|
| /info    | 200 RPS          | 2000 requests        | Yes (up to 20 sub-requests) |
| /exchange| 20 RPS           | 2000 requests        | No            |

Next Steps and Further Reading

Now that you understand Hyperliquid's rate limits, you can design your application to stay compliant. Start by implementing the production practices outlined above, and use the curl example to monitor your usage.

For more in-depth guidance, explore the OnFinality Learn hub for articles on RPC optimization, and check out the Hyperliquid network page for managed endpoints. If you need help with batching, read our guide on JSON-RPC batching.

If you are building a trading bot, consider using OnFinality's RPC Assistant to get the best endpoints for low latency. And for enterprise-scale needs, review our pricing and API service options.