How to get Hyperliquid data

Official API

The official Hyperliquid API supports most of the basic operations Hyperliquid users and builders need — retrieving (non-aggregated) user trade history, deposits/withdrawals, subscribing to wallet activity feeds, and fetching user positions.

Without going deep into rate limits (you can read about them here), the official API is mainly limited on these vectors:

• —Historical data: you can only retrieve a limited amount of actions.
• —Concurrent subscriptions: heavily rate-limited on how many concurrent wallets you can subscribe to.
• —Almost no aggregated/processed data: no separate liquidation stream, for example.

Running a node

A node is your own copy of the Hyperliquid machine, running on a server you control. Most of the time when people mention running a node, they mean a non-validator node. A non-validator node just listens — it streams every trade, order, and state change off the network and writes it to disk. Running one means:

• —Getting a beefy machine — 16 CPUs, 128 GB of RAM, 500 GB of fast storage.
• —Archiving data, as it spits out roughly 100 GB of logs every single day.
• —Optimizing — for best latency the node server has to be placed in the Tokyo region, and for stability it's recommended to find a stable peer.
• —Maintaining — it's a 24/7 operations commitment: finding peers, staying synced, handling crashes, monitoring.

When you run your own node, you get the full firehose locally — everything happening on Hyperliquid, in real time, with no rate limits and no dependency on someone else's API. You can also turn on a local server to answer your own queries and an EVM endpoint for HyperEVM data. It's the “own your data path” option.

HyperCore also has no archival node option. A fresh node only gives you data from the moment you start it forward. So if you want deep history, a node alone won't be enough — you'd either have been running it (and saving the files) the whole time, or you pull history from the S3 archives instead.

The cost of running a node with these requirements is around $1k/month, including server and data-archive costs. Running node(s) is usually a preference for teams:

• —Who want to keep and maintain all infra in-house.
• —Who are extremely latency-sensitive and want full control over how their market data is ingested.

For everyone else, it's worth asking: do you want a node, or do you want the data from the node? This is especially relevant because on HyperCore there are no alternative order-submission paths other than the official API — RPC in the traditional blockchain sense does not exist on HyperCore, and everyone goes through the official API. So the only purpose of running a node is to get the data streams. Turning that firehose into something you can build on is a second project most teams underestimate — and then they own it forever: every crash, every network upgrade, every schema change.

Data providers

This is the gap data providers fill. Instead of running node(s) yourself, you let a provider deliver the data — with SLAs, no public API rate limits, and historical data. For a team shipping anything to production, that trade-off — pay for clean data, skip the infra — is usually worth it, which is why most serious builders end up getting their data streams from a provider.

Choosing your provider

Different providers are good for different use cases (covered in depth in the section below). If we have to generalize the buying decision, ask:

• —Is your app or project multi-chain?
• —Do you need both HyperCore and HyperEVM, or is just HyperCore enough?
• —Do you need live streams, deep history, or both?