Hyperliquid REST

35 operations, every one a GET, all under https://data.vike.io/v1/hyperliquid/. This is the largest namespace in the API by some distance, and the only one with per-wallet history: who holds what, at what entry, with what realized PnL.

Every path in this namespace is written relative to https://data.vike.io/v1/hyperliquid. The fenced line at the top of each endpoint's page carries the full path.

Start here

What it looks like in use

# find: who earned the most realized PnL in 30 days, among wallets with at least 50 trades
curl -s "https://data.vike.io/v1/hyperliquid/leaderboard?window=30d&min_trades=50&limit=5" \
  -H "X-API-KEY: $VIKE_API_KEY"

# drill in: WALLET is a wallet value from that board; equity, cohort labels and risk metrics in one call
curl -s "https://data.vike.io/v1/hyperliquid/wallets/$WALLET?window=30d" \
  -H "X-API-KEY: $VIKE_API_KEY"

# what it holds right now
curl -s "https://data.vike.io/v1/hyperliquid/positions?wallet=$WALLET&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# how it got there: closed BTC trades, newest first
curl -s "https://data.vike.io/v1/hyperliquid/wallets/$WALLET/trades?coin=BTC&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# page through: NEXT is the previous response's nextCursor, passed back verbatim
curl -s "https://data.vike.io/v1/hyperliquid/wallets/$WALLET/trades?coin=BTC&limit=100&cursor=$NEXT" \
  -H "X-API-KEY: $VIKE_API_KEY"

Before you call anything

Auth. X-API-Key: vk_... or Authorization: Bearer vk_oat_...; either alone is enough. See Authentication. Every call spends one unit of the shared hourly counter — see Rate limits.

Errors. Every route in this namespace maps failures the same way: input the service rejected is a 400, an upstream data failure is a 503, and a rate-limit trip is a 429. A failure is never reported as a 200 with an empty body — a silent empty list is indistinguishable from "no data", which is how bad backfills get built on top of an outage. See Errors.

Pagination is keyset, not offset. The position-snapshot history is 7.3 billion rows and the fill history 1.07 billion; an offset re-reads and discards every skipped row, so deep pages cost linearly more and a concurrent insert shifts rows across page boundaries. Every list route returns nextCursor — pass it back verbatim, do not construct one.

Aggregates are snapped to a canonical precision before they leave. A large floating-point sum is not reproduced bit-for-bit run to run, so without that step two identical requests could come back differing in their last digits. Snapping them is what makes a response safe to cache, diff or content-address.

The cohort vocabulary

Four query parameters recur across this namespace: axis, cohort, labelBasis and grading. Cohorts and axes defines the ladders and Label basis says when a label was computed. Read both before hard-coding a bucket name.

Wallets

Seven routes. {address} is a Hyperliquid wallet address.

Builders

A builder is a front-end or bot that attaches its address to an order and is paid a slice of the taker fee for it. Six routes over builder-routed fills.

Cohorts and segments

Three self-describing routes. Read these before hard-coding any bucket name.

Coins

Hourly positioning series for one coin. {coin} is an HL coin ticker such as BTC.

Positions

Leaderboards

Liquidations

Three routes, and they answer two different questions — one realized, two hypothetical.

Ecosystem aggregates

Candles

Two routes, and they are the whole crypto candle surface: Hyperliquid candles, built from the fills our own node sees. There is no second venue's candle route to reconcile the numbers against, so the parameter table and the response envelope on the endpoint's own page are the entire contract.

Related

• Data MCP server — hl_perp_top_traders and hl_position_match run the same code as /traders and /positions/match, agent-shaped.
• Rate limits — the shared hourly counter these calls spend.
• Errors — the status codes and the error envelope.