Hyperliquid RPC vs Data API: Which is best for you?

Search for "Hyperliquid RPC" and you get a list of providers. Pick one, and you'll find it only covers part of what your app needs. That comes from how Hyperliquid is built.

Hyperliquid has two layers. HyperEVM is an EVM chain, with contracts, events, blocks and the usual JSON-RPC. HyperCore is the native order book, with orders, fills, positions and liquidations. RPC providers are built for the first layer. The second mostly runs through Hyperliquid's own API.

This guide covers what an RPC gives you, what it doesn't, and where a data API fits, with the actual endpoints for five common builds.

What a node gives you

Everything on Hyperliquid starts with the node. A non-validator running Hyperliquid's node software can do three things:

1. Serve HyperEVM JSON-RPC.
2. Serve a local /info server for about 30 requests that depend only on current state, such as positions, open orders, vaults, fees and metadata.
3. Write the raw firehose to disk: fills, order statuses, book diffs and other events. That's around 100 GB a day, written as files and not served over any API.

What a node can't do matters just as much. Hyperliquid's own README says the local server doesn't support historical time series queries or websockets. And no node places orders. On HyperCore, every order goes through Hyperliquid's API.

That's the real difference between an RPC and a data API. An RPC serves the first two. A data API takes the third, stores it, and turns it into something you can query.

If you're weighing whether to run a node yourself, How to get Hyperliquid data compares that against the other options, and our non-validator node guide covers the setup.

What a Hyperliquid RPC covers

An RPC provider runs nodes for you and puts an endpoint in front of them. You get HyperEVM JSON-RPC over HTTP and WebSocket, often with archive data, plus the current-state /info methods. The public HyperEVM endpoint is capped at 100 requests a minute, so a private one is worth having for anything in production.

Use one if you deploy contracts on HyperEVM, read events, or need a private endpoint for a bot.

An example, Chainstack runs Hyperliquid nodes for HyperEVM and HyperCore on mainnet and testnet, with archive data for HyperEVM.

What an RPC can't serve

Anything that needs history or aggregation isn't in a node's current state, so a standard RPC passes it through to Hyperliquid's public API. That's around 30 read methods, including:

• userFills, userFillsByTime and historicalOrders
• candleSnapshot, fundingHistory and userFunding
• l2Book, allMids, recentTrades and portfolio

Every /exchange action goes there too: order, cancel, modify, transfers and withdrawals. There's no private route for order submission on HyperCore.

Those calls then count against the public API's limits, which are tight for anything that reads many wallets. We break each one down in Hyperliquid Rate Limits.

For a bot trading one account, that's usually fine. For an app tracking thousands of wallets, it isn't.

Where a data API fits

Hydromancer is a Hyperliquid data provider, not an RPC. We run our own nodes, including a validator, and store and index what they write, with history back to July 2025. That lets you query the history and aggregates a node can't answer. REST calls use the same POST /info shape as the official API, and the WebSocket lives at wss://api.hydromancer.xyz/ws.

Hydromancer has its own limits, set by plan and much higher than the public API's: 5,000 to 50,000 weight a minute, with most requests costing 2. Batch endpoints stretch that further, since one batchClearinghouseStates call covers up to 1,000 wallets.

That covers reads only. Orders still go through Hyperliquid, and the order rate limit on your address stays the same.

Which one do you need?

Five builds, and the endpoints behind them

1. Copy trading app

A copy trading app does three jobs: find traders worth following, watch what they do, and watch what your own users do.

Pick the leaders. userPnlSummary returns realized PnL stats for any address: total PnL, win rate, number of trades, median hold time, fees and funding.

It also returns a "human score" from 0 to 100, so you can filter out wallets that are clearly bots before you list them.

Watch their positions. batchClearinghouseStates returns positions and margin for up to 1,000 wallets in one request. Against the official API, that's 1,000 separate clearinghouseState calls.

Polling positions on a timer is also your safety net. If a live message drops, the next position read shows you what the leader actually holds, so a copier never drifts for long.

Stream their fills. The userFills subscription takes a list of addresses, so one connection covers every leader.

Copy orders still go to Hyperliquid's official API. The data API tells you what to copy. It doesn't place the trade.

2. Trading frontend with a builder code

If your frontend earns builder fees, you want to know what your users trade and what you earn, as it happens.

Live. The builderFills stream sends every fill routed through your builder code.

Backfill and revenue reports. builderFillsByTime returns the same fills for any time range, up to 2,000 per page, with a cursor for the next page. Each fill includes builderFee, so revenue is a sum over the results.

Data goes back to July 28, 2025. The alternative, Hyperliquid's builder fill files, arrives one to three days late.

That range is August 2026. Pass the cursor from the last fill to get the next page.

Warn users when they get liquidated. builderLiquidations streams liquidations of your users. A liquidation goes to your channel if the user's last fill on that coin came through your builder code.

TWAP fills don't carry builder codes, so they don't count.

3. Liquidation dashboard

The official API has no liquidation feed. You'd have to read every fill and filter for liquidations yourself.

Live. liquidationFills streams every liquidation on Hyperliquid, batched per block.

History. liquidationHistoryByTime returns past liquidations for one market, or across all markets if you leave coin out. HIP-3 markets use the dex:COIN form, such as xyz:JPY. Up to 1,000 events per request, newest first.

Each event includes the liquidated address, size, price, mark price, and whether it was closed against the book (market) or absorbed by the backstop liquidator (backstop). That's enough for a heatmap, a biggest-liquidations feed, or a per-market chart.

Our guide to building with liquidation data on Hyperliquid goes further.

4. Market making and order book analytics

The official l2Book shows price levels. It doesn't show who is behind them.

L4 stream. l4BookUpdates streams every change to the order book, per block, with the address behind each order. You can see queue position, spot a large maker pulling liquidity, or rebuild the book yourself.

L4 snapshot. The l4Book REST endpoint returns every resting limit order across all perp markets, with addresses, refreshed every second. Use it to seed your local book before applying stream updates. It's limited to 10 requests per 5 minutes, which is plenty for a seed.

If you only need top of book or aggregated levels, bbo and l2Book streams are available too.

Our post on BBO vs L2Book vs L4Book covers which one fits.

5. HyperEVM app with a HyperCore side

This is the setup that needs both an RPC and a data API.

Take a vault or lending protocol on HyperEVM whose users also hold positions on HyperCore. Contract state, deposits and events come from an RPC.

The HyperCore side comes from the data API: batchPortfolioStates returns perp and spot balances for up to 500 users at once, or 100 with "dex": "ALL_DEXES" to include every HIP-3 market.

Neither source covers both layers alone, so most teams in this spot run one of each.

Getting started

Get an API key from the Hydromancer docs. Every REST call goes to the same endpoint:

For WebSocket, add your key to the URL: wss://api.hydromancer.xyz/ws?token=YOUR_KEY.

For full history, Reservoir has every HyperCore fill, candle and book snapshot, free.

Summary

Use an RPC for HyperEVM. Send orders through the official API. Add a data API when your app reads HyperCore at scale: many wallets, builder fills, liquidations or full order book depth.