> ## Documentation Index
> Fetch the complete documentation index at: https://goldrush.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Hyperliquid API Rate Limits, Caching & Polling

> The public Hyperliquid /info API is capped at 1200 request weight per minute per IP. The GoldRush Hyperliquid Info API removes that rate limit entirely - poll any endpoint as fast as you need.

## Hyperliquid API rate limits

The **public Hyperliquid `/info` API** is rate limited to **1200 request weight per minute per IP address**. Every `/info` request carries a weight cost, so heavy usage - polling many wallets, refreshing market state frequently, or running a fleet of workers behind one IP - hits the cap quickly and starts getting throttled.

**The GoldRush Hyperliquid Info API removes this limit entirely.** It's a [drop-in `/info` replacement](https://goldrush.dev/docs/goldrush-hyperliquid/info-api/migration) on `hypercore.goldrushdata.com/info` with byte-for-byte identical request and response shapes, but **no per-IP, per-key, or per-address rate limits**.

## No rate limits with GoldRush

With no weight cap and no per-IP throttling, you can:

* Poll any user-state endpoint as fast as your code wants.
* Open as many concurrent connections as your client supports.
* Pull state for thousands of wallets in tight loops.

For wallet-level real-time updates without polling at all, use the [`walletTxs` subscription](https://goldrush.dev/docs/goldrush-hyperliquid/streaming/wallet-firehose) instead - push-based, also no rate limits.

## How caching works

Responses are served from a real-time cache that's kept fresh by direct ingestion from Hyperliquid. The cache is transparent to your client code - same JSON in, same JSON out.

| Cache layer | Typical freshness |
| - | - |
| User-state types (`clearinghouseState`, `spotClearinghouseState`, `frontendOpenOrders`) | Sub-second after each user event. |
| Market types (`metaAndAssetCtxs`) | Sub-second on every mark-price tick. |

## Recommended polling cadences

You're not rate-limited, but polling smartly saves your own bandwidth.

| Endpoint | Recommended interval | Notes |
| - | - | - |
| `metaAndAssetCtxs` | 1 second | Mark prices update on every tick. |
| `clearinghouseState` | 1 second per user, OR push via [`walletTxs`](https://goldrush.dev/docs/goldrush-hyperliquid/streaming/wallet-firehose) | Account state only changes on a user event; push is far more efficient than polling. |
| `spotClearinghouseState` | 5 seconds | Spot balances change less frequently than perp positions. |
| `frontendOpenOrders` | 1 second per user, OR push via `walletTxs` | Same as `clearinghouseState`. |

## Watch out for client-side limits

GoldRush has no rate limits, but the rest of your stack might:

* **Browser fetch concurrency** - most browsers cap at \~6 concurrent requests per host. Use connection pooling on the server side or batch requests.
* **HTTP/2 stream limits** - most clients allow 100+ concurrent streams per connection by default. Bump if you're saturating.
* **OS file descriptor limits** - if you're opening thousands of connections, raise `ulimit -n`.

For multi-wallet fan-out, use the [`batchClearinghouseState`](https://goldrush.dev/docs/api-reference/hyperliquid-info/batch-clearinghouse-state) and [`batchSpotClearinghouseState`](https://goldrush.dev/docs/api-reference/hyperliquid-info/batch-spot-clearinghouse-state) endpoints, which accept up to 50 wallets per call. For more than 50 wallets, issue multiple calls.

## Network and TLS

* **HTTP/2** keep-alive is supported and recommended.
* **TLS 1.2+** required.
* **`Accept-Encoding: gzip`** is honored. `zstd` support is on the roadmap.

## Need higher guarantees?

Enterprise SLA, dedicated capacity, regional pinning, and on-prem options are all available. [Email sales](mailto:sales@goldrush.dev?subject=Hyperliquid%20API%20-%20Enterprise%20Inquiry).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.