> ## 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](/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 [Streaming API `walletTxs` subscription](/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 - for sub-second freshness, use the Streaming API.  |
| `clearinghouseState`     | 1 second per user, OR push via [`walletTxs`](/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`](/api-reference/hyperliquid-info/batch-clearinghouse-state) and [`batchSpotClearinghouseState`](/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).