Hyperliquid API Rate Limits, Caching & Polling

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 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 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`	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 and batchSpotClearinghouseState 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.