Skip to main content
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.
Usage is billed in compute units. See Compute units & pricing for how metering and plans work.

​
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.
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.

​
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.
  • Stream instead of poll for order books. If you’re polling l2Book on a tight loop, switch to the WebSocket l2BookDiff channel — 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: 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 for the full list.