Hyperliquid API: Public Data vs Trading Access

The Hyperliquid API is two different things wearing one name. There is an info endpoint that returns public market and account state (order books, candles, user positions, funding) with no key required, and there is an exchange endpoint that accepts cryptographically signed actions to place, cancel and modify orders against your own wallet. Per the Hyperliquid API documentation, both are HTTP POST endpoints with an additional WebSocket channel for live subscriptions, and the split between them is the single most important thing to get right before you write any code.

Why it matters now

The read path is open and forgiving. The write path is a signing problem where key hygiene decides whether your funds survive. Picking the wrong surface costs you either wasted engineering or a drained account, so the distinction is worth settling before the first line of code.

Key takeaways

• The read path (info endpoint and WebSocket) needs no authentication. You can pull order books, mids, candles and any wallet's open positions with a plain POST request.
• The write path (exchange endpoint) requires an EIP-712 signed payload. Every order, cancel and transfer is a signed action, so a leaked API wallet key can move funds.
• Hyperliquid supports a separate API wallet (also called an agent wallet) that can trade on your behalf but cannot withdraw, which is the recommended way to run a bot.
• Rate limits are weight-based and tied to address, not to an API token, so throttling behaves differently from a typical centralized exchange.
• For historical or cross-wallet analysis the live API is the wrong tool. It serves current state, not a queryable archive of every matched trade.

The read path: public data with no key

The info endpoint is where most people start, and it is genuinely open. According to the the info endpoint docs, you POST a JSON body with a type field to a single URL and get structured JSON back. Request l2Book for an order book snapshot, allMids for mid prices across every market, candleSnapshot for OHLC bars, and clearinghouseState with a user address for that wallet's perpetual positions and margin.

Because the info endpoint takes an address as a parameter, you can read anyone's open positions. This is what people mean when they say Hyperliquid is transparent: account state that a centralized venue keeps private is queryable here. The WebSocket channel pushes the same families of data as live subscriptions (l2Book, trades, user events) so you are not polling.

What the info endpoint does not give you is a warehouse. Ask it for the order book now and you get the book now. Ask for every trade a wallet made last month and there is no single call that returns it. That gap is where the two surfaces of the API stop being interchangeable.

The write path: why every order is a signature

The exchange endpoint is where trading happens, and it does not take a password. Per Hyperliquid's documentation, each action (place order, cancel, modify, transfer) is serialized and signed with your wallet's private key using EIP-712 typed-data signing, then POSTed with the signature attached. The chain verifies the signature before executing. There is no server-side session to hijack, but there is also no reset-my-key button, so key handling is the whole game.

This is why Hyperliquid exposes API wallets. You approve a separate agent wallet from your main account, and that agent can sign trading actions but cannot withdraw funds. If the agent key leaks, an attacker can trade your positions but cannot drain the account to an external address. Anyone running an automated strategy should trade through an API wallet rather than the master key, and the official Python and Rust SDKs linked from the docs handle the signing so you are not hand-rolling EIP-712.

Rate limits are tied to the address, not a token

On a typical exchange you get an API key with a request quota. Hyperliquid instead applies weight-based limits keyed to the account address, with separate budgets for info requests and for order actions. The practical consequence: spinning up a second API key does not buy you more throughput on the same account, and heavy read traffic and heavy order traffic draw from different buckets. Check the current limits in the the exchange endpoint docs before you size a strategy, because these numbers move.

Where the live API stops: historical and cross-wallet questions

The read endpoints answer what is true right now. A large class of real questions are about what was true, across many wallets, over a window. How much notional traded last week? How many wallets got liquidated? How does activity on a builder-deployed market compare to the core venue? None of those is a single info call.

To make the problem concrete, consider what one matched perp trade needs to carry to be analyzable: a unique trade id, both the buyer and seller address, the raw amount, the price, a USD notional, and an explicit direction per side so an open is distinguishable from a close. Pull that live and you get a stream you have to catch, order and store yourself, forever, without dropping a message. Pull it for a wallet's full history and the endpoint does not offer it.

This is the gap Allium's Hyperliquid tables close. The hyperliquid.dex.trades table resolves every one of those fields per row, with one row per matched trade rather than one per side. In a recent window the table carried 44,010,759 distinct trade_ids across 44,010,086 trades, holding $66.78B in notional. Because each row holds both buyer_address and seller_address with explicit buyer_dir and seller_dir fields, a matched trade is counted once rather than double-counted across maker and taker, and an open can be told apart from a close. (Allium data, 7 days to 2026-09-23.)

A worked read on that same table

The direction field is where notional stops being mysterious. Here is why a big headline number is not capital at risk:

Opens and closes are near-symmetric because the same position contributes once on entry and once on exit. The $66.78B measures trading activity, not unique dollars deployed. Cross versus isolated margin is visible in the same field, with liquidated cross long and liquidated isolated long appearing as distinct directions. The live API, which shows a position's current state, cannot reconstruct that split after the fact. (Allium data, 7 days to 2026-09-23.)

The same table separates the venue's own markets from HIP-3 builder-deployed perp DEXs that settle on Hyperliquid:

Liquidations show up in the same structure. Over that window, market liquidations ran 120,351 trades for $546.0M across 28,587 distinct users, while the backstop path (the venue's last-resort mechanism) fired just 20 times for $635.5K across 20 users. That contrast grounds any discussion of insurance funds and auto-deleveraging in observed events rather than theory. (Allium data, 7 days to 2026-09-23.) Figures here cover Hyperliquid and its HIP-3 deployments only and should not be extrapolated beyond the window.

Which surface you actually need

Decide which row you are in before you write code. The read path is open and forgiving. The write path is a signing problem where key hygiene decides whether your funds are safe. And the moment the question becomes historical or cross-wallet, you have left the live API entirely.

Frequently asked questions

Do I need an API key to use the Hyperliquid API?

Not for reading data. The info endpoint and WebSocket return order books, prices, candles and any wallet's live positions without authentication. Trading is different: the exchange endpoint requires each action to be signed with your wallet's private key via EIP-712, so there is no traditional API key, just a signature.

What is a Hyperliquid API wallet (agent wallet)?

An API wallet is a separate address you authorize to sign trading actions on your account without the ability to withdraw funds. It is the recommended way to run a bot, because a leaked agent key can trade your positions but cannot move money off the account. Hyperliquid's official SDKs handle the signing for an approved agent.

Can I pull my full Hyperliquid trade history from the API?

Not as a single query. The live endpoints serve current state and recent events, not a complete queryable archive across time or across many wallets. For full history you either capture and store the WebSocket stream yourself or query a dataset like Allium's hyperliquid.dex.trades table, which holds one row per matched trade with both sides and USD notional.

How do Hyperliquid API rate limits work?

Limits are weight-based and tied to the account address rather than to an API token, with separate budgets for info requests and for order actions. Creating a second key does not add throughput to the same account. Check the current weights in Hyperliquid's documentation before sizing a strategy, since they change.

Does the Hyperliquid API expose funding rates?

The live info endpoint returns funding data in its current-state responses per the official docs. Historical trade datasets vary in what they carry, so confirm the specific schema you are querying before assuming a funding-rate field is present.

Can the Hyperliquid API read other people's positions?

Yes. Because account state is onchain, the info endpoint accepts any address and returns that wallet's open perpetual positions and margin via clearinghouseState. This transparency is a core difference from centralized venues, where account state is private.

Interested in learning more about Allium’s onchain data infrastructure? Speak to someone on the team.

Allium provides onchain data infrastructure. Companies named in this article may be Allium customers, prospects or commercial counterparties. The authors and other Allium personnel may hold positions in the assets discussed. This article is informational only and is not investment, legal or tax advice. Data and information last reviewed: October 12, 2026.