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

# Rate Limits, Caching & Polling

> How the Uniblock Hyperliquid Info API removes the public request-weight cap, and how to poll and cache efficiently.

Hyperliquid's public `/info` API enforces a request-weight budget per IP address, so high-frequency polling and multi-user reads quickly hit the ceiling. Routing through Uniblock removes that constraint — usage is metered in **compute units** against your project instead of throttled per IP.

<Info>
  Usage is billed in compute units. See
  [Compute units & pricing](/reference/resources/pricing-plans) for how metering
  and plans work.
</Info>

## No public request-weight cap

The public API assigns each `/info` operation a weight and limits the total weight per minute per IP. Uniblock does not apply that per-IP cap. Instead:

* Requests are metered in compute units per call, not throttled by a per-IP weight budget.
* Uniblock's provider waterfall spreads load and fails over automatically, so a single provider's limits don't become yours.

<Note>
  This removes the *per-IP* cap — it does not make the API unlimited. Your
  project still has **plan-level rate limits**: bursts above your plan's
  allowance return `429`, and backup routing does not bypass them. Keep
  retry/backoff logic in place. See [Rate limits](/guides/uniblock/error-codes#rate-limits).
</Note>

## Poll efficiently

Without the per-IP cap you can poll harder, but do it deliberately — you're billed per request and still bound by your plan's rate limit:

* **Match your poll interval to how fast the data changes.** Order books and mark prices move every block; account state changes far less often.
* **Batch multi-user reads.** Replace one request per user with a single synthetic batch type — `batchClearinghouseStates` or `batchPortfolioStates` (up to 50 users per request). See the [Info API overview](/guides/hyperliquid/info-api/overview).
* **Stream instead of poll for order books.** If you're polling `l2Book` on a tight loop, switch to the [WebSocket `l2BookDiff` channel](/guides/hyperliquid/websockets/l2-book-diff) — you get per-block updates without repeated REST calls.

## Cache read-mostly data

Some `/info` responses change rarely and are safe to cache client-side:

| Data                                        | Typical cache window          |
| ------------------------------------------- | ----------------------------- |
| `meta`, `spotMeta` (asset universe)         | minutes to hours              |
| `metaAndAssetCtxs` (contexts + mark prices) | seconds                       |
| `clearinghouseState`, `portfolioState`      | seconds                       |
| `l2Book`                                    | do not cache — stream instead |

Cache the slow-moving metadata once at startup and refresh it on a long interval, rather than fetching it alongside every hot read.

## Handling errors

* A body without a supported `type` returns `400` at the HTTP boundary before reaching a provider — validate your `type` client-side.
* A `429` means your project exceeded its plan-level rate limit — retry with exponential backoff and jitter, and upgrade your plan if demand is sustained.
* Transient upstream failures are retried across the provider waterfall automatically. See [Error codes](/guides/uniblock/error-codes) for the full list.