The Hyperliquid Orderflow API: CVD, VPIN, and Whale Data Over REST

Hyperliquid's public /info endpoint returns prices, funding rates, open interest, and raw L2 order books. It does not return cumulative volume delta. It does not return VPIN, order book imbalance, order flow imbalance, or Kyle's Lambda. It does not tell you which wallet just opened a $4 million short on HYPE.

Those are derived metrics. Computing them yourself means running a persistent websocket ingest, buffering the trade tape, bucketing by volume rather than time, and doing all of it while staying under a rate limit of roughly 1,200 weight per minute that punishes you for polling too hard. That is the infrastructure problem the Buildix Hyperliquid API removes.

Where the Hyperliquid Public API Stops and Orderflow Begins

The gap is not about data access. Hyperliquid is one of the most open venues in crypto: the tape is there, the book is there, every fill is on chain. The gap is about state.

CVD is a running sum, so it is worthless without continuity. Lose your websocket for ninety seconds during a liquidation cascade and your delta is silently wrong for the rest of the session. VPIN needs volume buckets, not time buckets, which means you need the full tape and a bucketing engine that survives restarts. Kyle's Lambda needs a regression over price impact against signed volume across a rolling window.

Every one of those is a stateful pipeline you have to run, monitor, and backfill. The Buildix crypto orderflow API returns them as fields in a JSON response.

Eleven REST Endpoints Across 530+ Pairs

The v1 surface covers three layers: market-wide, per-pair, and wallet-level.

Market-wide endpoints return the whole universe in one call. /api/v1/screener gives every tracked pair with price, volume, open interest, funding, and a composite signal score. /api/v1/signals returns the current orderflow signal set. /api/v1/funding-arb returns predicted funding across venues for carry and basis strategies. /api/v1/smart-money surfaces aggregate positioning from tracked wallets.

Per-pair endpoints go deep on a single symbol. /api/v1/pair/{symbol} returns the snapshot. /api/v1/deep-view/{symbol} returns the full orderflow payload: CVD, OBI, VPIN, Kyle's Lambda, volume profile, and regime classification with the candle interval used to compute it.

Wallet-level endpoints are the ones with no equivalent anywhere else. /api/v1/whales lists tracked wallets. /api/v1/whales/{address} returns state for any address, tracked or not. /api/v1/whale-moves returns position changes with keyset pagination. /api/v1/wallet/{address}/fills returns execution history and /api/v1/wallet/{address}/pnl returns realized and unrealized performance.

Coverage includes HIP-3 markets, so oil, gold, equity index and forex perps come through the same endpoints as BTC and HYPE. Most analytics vendors do not carry Hyperliquid at all, and the ones that do treat HIP-3 as out of scope.

Authentication, Quotas, and What the Headers Tell You

Authentication is a bearer token. Generate a key from Dashboard, then send it on every request:

curl "https://www.buildix.trade/api/v1/screener" \ -H "Authorization: Bearer bx_live_YOUR_KEY"

In Python it is three lines:

import requests r = requests.get("https://www.buildix.trade/api/v1/deep-view/BTC", headers={"Authorization": "Bearer bx_live_YOUR_KEY"}) print(r.json()["orderflow"]["cvd"], r.json()["vpin"])

Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Tier, so a client can back off before it gets throttled instead of after. A 429 returns a Retry-After in seconds along with the window and scope in the body, which means retry logic can be exact rather than exponential guesswork.

Daily quotas are what matter for anything running unattended. The Whale plan at $79 a month includes 2,000 requests per day across five keys. The API plan at $249 a month includes 50,000 requests per day with unlimited keys, which is the tier built for desks polling the full universe on a schedule rather than a single trader checking a few pairs.

The Response Contract: Knowing When Data Is Partial

Most analytics APIs return a number and leave you guessing whether it is fresh. That is fine for a dashboard and dangerous for anything that sizes a position.

Every deep-view response declares its own coverage. The data field is either full or partial. When it is partial, reason explains why and missing lists exactly which inputs were unavailable, whether trades, book, or candles. A stale flag and stale_sources identify which specific feed is behind, and data_ts carries a timestamp per source rather than one timestamp for the whole payload.

Symbols outside the tracked top tier still return snapshot fields, with orderflow metrics explicitly null instead of silently zero. That distinction matters more than it sounds. A zero CVD and an unavailable CVD are different states, and a strategy that treats them the same will take trades on absent data.

Endpoints read from a precomputed cache layer rather than proxying Hyperliquid on demand, so latency is deterministic and your requests never contend with the venue rate limit. When a producer is behind, the endpoint returns a 503 with a Retry-After rather than a stale number dressed up as a live one.

Which Plan Fits What You Are Building

A backtest that pulls the screener once an hour fits inside Whale comfortably. A signal service that polls fifty pairs every five minutes does not: that is 14,400 calls a day and it belongs on the API plan. Anything with unattended retries or multiple environments wants unlimited keys, because rotating a compromised key without downtime requires having a second one already live.

Full endpoint documentation with example responses for each route is at buildix.trade/developers, and plan limits are at buildix.trade/pricing. Keys are generated in the dashboard and work immediately.

The orderflow metrics that separate informed flow from noise were institutional infrastructure five years ago. On Hyperliquid they are now a GET request.