Hyperliquid API Rate Limits Explained (With Fixes)

Hyperliquid’s official REST API has a shared limit of 1,200 weight points per minute per IP. Trading actions also face separate address-based limits, while WebSocket connections and subscriptions have their own caps. Increasing your polling interval can help with one limit without solving the others.

The practical question is not just “How many requests can I send?” It is “Which requests does my application need to make?”

This guide explains the limits, then works through three examples: refreshing a wallet dashboard, streaming order books and backfilling trade history.

First, identify which limit you are hitting

These are different mechanisms. In particular, moving market-data reads to another provider does not remove Hyperliquid’s limits on trading actions.

System 1: Per-IP limits

REST: request weight, not simply request count

The official REST API combines requests into a 1,200-weight-per-minute budget per IP. Different requests consume different amounts.

Historical endpoints such as userFills, userFillsByTime, historicalOrders, fundingHistory and userFunding add weight for returned items. The surcharge is one point per 20 items; candleSnapshot adds one per 60 items.

For example, a userFills response containing 2,000 fills costs 120 points: 20 base points plus 100 for the returned fills. Ten such responses consume 1,200 points—the entire minute’s budget, before any other requests.

This matters when a dashboard and trading service share an outbound IP. Their REST reads and exchange requests draw from the same IP budget. Heavy data fetching can leave less capacity for placing or cancelling orders.

WebSocket: connections are only one constraint

The official limits apply per IP:

Opening more connections from the same IP does not raise the ten-user cap. A wallet tracker needs to count the distinct users in its subscriptions, not just its sockets.

For a broader explanation of available streams, see Hyperliquid data feeds: every real-time stream, explained.

HyperEVM RPC

The public rpc.hyperliquid.xyz/evm endpoint allows 100 JSON-RPC requests per minute per IP. This is a separate interface from the HyperCore info and exchange APIs; its allowance should not be treated as their request budget.

System 2: Address-based trading limits

Hyperliquid also limits trading actions per address. The allowance grows by one request per USDC of cumulative traded volume, with an initial buffer of 10,000 requests. Once rate-limited, an address is allowed one request every ten seconds. These limits apply to actions, not info queries, and subaccounts are treated as separate users.

Three details matter:

• Cancels have additional headroom. Their cumulative limit is min(limit + 100,000, limit × 2), where limit is the normal action allowance. This is extra capacity, not unlimited cancellations.
• Batching does not reduce address usage. A batch of 79 orders is one HTTP request with an IP weight of two, but it still counts as 79 requests against the address allowance.
• Open orders have a separate cap. The default is 1,000, increasing by one per 5 million USDC of volume, up to 5,000. When an account already has at least 1,000 open orders, new reduce-only and trigger orders are rejected.

If actions are throttled while data queries still work, inspect the official userRateLimit response. It exposes cumulative volume and request-usage fields; looking only at your HTTP requests per second can miss the actual constraint.

System 3: Congestion limits

During high congestion, an address is limited to twice its previous-day maker share of block space. The share is calculated once per UTC date and uses the same asset scaling as volume contributions toward fee tiers.

A larger data-provider plan does not change that allocation. Under congestion, avoid repeatedly resending cancels whose results have already been returned. Separate the need for fresher market data from the need to submit another trading action.

During congestion, Hyperliquid weighs a batched action by its batch size plus a fixed per-action weight, so batching orders or cancels together lowers your usage under this limit.

The history limit that retries cannot fix

The official userFills endpoint returns at most the 2,000 most recent fills. userFillsByTime returns at most 2,000 fills per response and makes only the most recent 10,000 fills available.

That is a data-availability limit, not just a throughput limit. Waiting for a new minute or retrying the same query does not recover records outside the endpoint’s available history.

For older records, choose a source with the coverage you need. Check the dataset, market and date range rather than treating “historical data” as a promise of complete history for every address.

What changes with Hydromancer?

Hydromancer’s data API uses tiered, per-key allowances rather than the official API’s per-IP REST budget. The published REST and WebSocket limits are:

The REST weight table and WebSocket limits are the references to use for capacity planning. Weights are provider-specific; an official API weight point is not a universal unit that transfers between providers.

Hydromancer’s default REST request weight is two, but exceptions include ten-point historical-fill requests, twenty-point performance endpoints, hundred-point builder-approved history endpoints and per-user batch pricing. Certain market-data snapshots also have a separate limiter: five calls per ten minutes, with l4Book allowing ten per five minutes.

For supported multi-address WebSocket feeds, each address counts toward the total subscription allowance. “Unlimited per key” in a channel-specific row does not remove the plan’s total subscription cap. All-market feeds also have separate permission requirements.

The benefit is therefore not “no limits.” It is a different data allowance and additional ways to organise queries. Reads sent to Hydromancer no longer consume the official API’s IP budget, but trading actions sent to Hyperliquid remain subject to its rules.

Hyperliquid vs Hydromancer Rate Limit: Side-by-side Comparison & Test

The tables above are published limits. Here’s what they mean for the requests people actually send, tested side by side on 30 October 2026. Hyperliquid’s API was called from a server in Tokyo, and Hydromancer’s with an API key. Hydromancer’s weight for every request is listed in its rate-limit table.

How to read the tables: weight is the price of a request, paid out of a per-minute allowance, so a lower weight is better. “Per minute” is how many of that one request fit in a minute if you send nothing else, so a higher number is better. Hyperliquid’s budget is 1,200 weight per minute per IP address, shared with your trading. Hydromancer’s is per API key: 5,000 on Starter, 20,000 on Growth and 50,000 on Scale.

#1: Fill history: userFillsByTime

Hyperliquid keeps only each wallet’s latest 10,000 fills, so for a busy wallet an older window comes back empty. Waiting or retrying doesn’t change that.

Hydromancer docs: userFillsByTime, and userFills for the latest 2,000 fills.

#2: Wallet positions: clearinghouseState vs batchClearinghouseStates

Hydromancer docs: clearinghouseState and batchClearinghouseStates.

#3: Funding payments: userFunding

Hydromancer docs: userFunding.

#4: Candles: candleSnapshot

Hyperliquid keeps only about the latest 5,000 candles for each market and interval.

Hydromancer docs: candleSnapshot.

#5: Order books: l2Book

This is the one row where Hyperliquid allows more polling. Hydromancer’s order-book requests are meant for an occasional snapshot, and its stream is the way to follow a book continuously (see “Stream order books instead of polling them” below).

Hydromancer docs: l2Book for snapshots, and the l2Book stream for live updates.

What hitting the limit looks like

Because Hydromancer reports the cost and the remaining budget on every response, your code can slow down before it hits the limit instead of finding out from an error. The headers and the recommended retry approach are explained in Hydromancer’s handling rate limits guide.

Three practical ways to reduce API requests

The examples below are calculations using published limits and documented request formats, not measured performance benchmarks. They exclude unrelated traffic and retries; production applications should leave headroom rather than operate at a limit continuously.

1. Refresh 100 wallets with a batch request

Suppose a dashboard refreshes the native perpetual positions of 100 wallets every ten seconds. Calling the official clearinghouseState endpoint separately for each wallet produces 600 requests per minute. At two points each, that consumes the full 1,200-weight IP budget.

Hydromancer’s batchClearinghouseStates accepts multiple addresses in one request. Its published weight is two points per user, capped at 100 points per request. The same refresh schedule therefore uses six batch requests and 600 Hydromancer weight points per minute.

This is not just a larger allowance: it also reduces the number of HTTP requests your application manages.

Implementation details matter:

• Put the wallet addresses in the endpoint’s users array. Omitting dex selects the native DEX.
• Inspect both successful_states and failed_wallets. Retry failed addresses rather than repeating successful work.
• Treat ALL_DEXES separately. It reduces the maximum batch size from 1,000 to 100 users, and the published cost is multiplied by the number of DEXes.

See the batchClearinghouseStates request and response schema.

2. Stream order books instead of polling them

Polling ten markets once per second creates 600 official l2Book requests per minute. At two points per request, that also consumes the entire 1,200-weight minute.[1]

For a continuously updating display, use a WebSocket stream. The official API supports live data subscriptions; Hydromancer additionally documents multi-coin l2Book subscription messages.[1][6]

For example, send this payload over an authenticated Hydromancer WebSocket connection:

This is a subscription payload, not a complete connection client. Connection setup, heartbeat handling and reconnection still need to be implemented.

For a multi-coin subscription, data is an array of snapshots. Keep the latest snapshot for each coin and replace that coin’s stored book when a new snapshot arrives. Do not parse the array as a single book or apply full snapshots as incremental price-level changes.

Serve that cached state to your application rather than having each viewer poll upstream. This removes recurring REST book requests, but the WebSocket’s coin, subscription and message limits still apply.

Choose the amount of detail you actually need. Our BBO vs L2Book vs L4Book guide explains the trade-offs between top-of-book prices, aggregated depth and individual orders.

3. Backfill a fixed time range and save your progress

A backfill should move through history, not repeatedly download the latest page.

Hydromancer’s userFillsByTime supports time-range queries and a cursor composed of the last record’s time and txIndex, separated by an underscore. Its published request weight is ten points.

A practical backfill sequence is:

1. Choose a fixed startTime and endTime, in Unix milliseconds.
2. Request the first page and save the returned records.
3. Build the next cursor from the final record’s time and txIndex. When a cursor is supplied, startTime is ignored.
4. Keep the same endTime on subsequent requests so the target range does not keep moving.
5. Persist your checkpoint only after the page has been stored successfully. Use deduplication so retrying a page does not create duplicate records.
6. Run requests through a bounded queue, leaving capacity for live application queries.

Do not replace the documented composite cursor with a timestamp-only shortcut. The API exposes both components for pagination.

Coverage still matters. Hydromancer documents full fill availability from 28 July 2025, with earlier history available for most traders but exceptions for some high-volume addresses. TWAP fills are included from 2 August 2025.

For bulk market research, downloading date-partitioned archive files may be more appropriate than querying wallets individually. Reservoir’s Hyperliquid historical S3 archive explains the datasets and access model. It requires no Hydromancer API key, but uses AWS requester-pays S3, so AWS request and transfer charges can apply.

Reservoir’s Hyperliquid page specifies complete data from 28 July 2025 onward. Check the relevant dataset’s coverage instead of assuming every record since the exchange’s launch is available.

Measure the workload before increasing capacity

Log the endpoint, request frequency, response status and retry count for each service. For WebSockets, track active subscriptions and reconnect attempts as well as connection count. This helps distinguish useful traffic from repeated failures or unnecessary refreshes.

Hydromancer’s apiUsage endpoint provides daily statistics by request type, including total, successful and failed requests, average processing time and billable tokens consumed.

The request body for a seven-day view is:

Send it to the authenticated REST API using the apiUsage documentation. Daily totals are useful for finding expensive workloads, but they do not replace minute-level client logs for diagnosing bursts. Billable tokens should not be assumed to equal rate-limit weight points.

When a request is throttled, avoid immediate retry loops. Honour a retry delay if the service provides one; otherwise use bounded exponential backoff with jitter. For trading actions, reconcile the result before resubmitting rather than treating every timeout as proof that the original action failed.

Frequently asked questions

The official REST budget is 1,200 weight points per minute per IP. Endpoint weights vary. Trading actions also face address-based allowances and congestion limits, while WebSockets have separate connection, subscription and message caps.

They share the official REST IP budget. Address-based limits apply to actions, not info queries. Moving reads to another data provider reduces use of the official IP budget but does not remove trading limits.

It reduces IP-weight consumption compared with sending each order separately. A batch of 79 orders costs two IP-weight points, but still counts as 79 requests against the address allowance.

They can replace repeated REST polling, but they have their own limits. The official service allows ten unique users across user-specific subscriptions per IP, regardless of how those subscriptions are divided between connections.

The official userFillsByTime endpoint only makes the most recent 10,000 fills available. To retrieve older records, use an archive or historical-data API with suitable coverage; retrying the official endpoint does not extend its history.

When your workload fits its limits and available history, you may not need another provider. First eliminate unnecessary polling and duplicate requests. Consider a different data source when you need more users, broader history, different query shapes or separate capacity for data reads.

The takeaway

Batch related reads, stream changing data and checkpoint historical backfills. Those changes address the work generating the traffic, rather than just increasing the number of requests you can send.

Keep trading-action limits separate from data access, and check coverage separately from throughput. A larger request allowance cannot recover missing historical records or change the exchange’s rules for placing orders.

Sources

#1: Hyperliquid Rate Limits

#2: Hyperliquid Info Endpoint

#3: Hydromancer REST Limits

#4: Hydromancer WebSocket Limits

#5: Batch Clearinghouse States (Hydromancer docs)

#6: L2 Book Streaming (Hydromancer docs)

#7: Historical Fills by Time (Hydromancer docs)

#8: Reservoir Overview (Hydromancer docs)

#9: Reservoir Hyperliquid Coverage (Hydromancer docs)

#10: API Usage Statistics (Hydromancer docs)