The Hyperliquid API: what it does and how access works
Verified against Hyperliquid docs: Nonces and API wallets and Hyperliquid docs: Rate limits and user limits · by Hyperliquid Academy
Two endpoints, two very different things
info is public. Prices, order books, funding rates, market metadata, any address’s positions and fills. No key, no account, no signature — the same data this site reads to keep its own figures live.
exchange is where actions happen: placing and cancelling orders, transfers, leverage changes. Every request is signed.
The split is worth internalising because it explains why “is there an API key?” has an unsatisfying answer. There is no key to generate in a settings page. There is a signature, and what does the signing is either your wallet or an agent you have authorised.
The agent-wallet model
This is the part that differs from every centralised exchange, and it is a genuinely better design.
You approve an API wallet — an agent — that signs on behalf of your master account or its sub-accounts. That agent can place and cancel orders. It cannot withdraw.
So a leaked bot key is a bad day, not a catastrophe. Someone could trade your account into a loss. They could not send your balance anywhere, because moving funds off the exchange needs a signature from the master wallet.
Never reuse a deregistered agent address
The documentation is unusually blunt about this: once an agent is deregistered, its used nonce state may be pruned, so an action it signed previously could be replayed.
Generate a fresh agent each time. Reusing an address you have already retired is the one API mistake here with a security consequence rather than an inconvenience.
One more practical note that catches people on day one: to query an account you pass the actual master or sub-account address, not the agent’s. Querying with the agent address returns empty data and looks like a bug.
The limits
Two systems apply at once, and they constrain different things.
Per IP
| Limit | Value |
|---|---|
| REST weight budget | 1200 per minute |
| WebSocket connections | 10 |
| WebSocket subscriptions | 1000 |
| WebSocket messages | 2000 per minute |
Weight is not one per request. Most info requests cost 20, a handful of common ones cost 2, and exchange requests cost 1 plus a fraction of the batch length. So the budget goes much further on order placement than on data polling — which is a deliberate nudge toward the WebSocket.
Per address
| Limit | Value |
|---|---|
| Initial request buffer | 10000 requests |
| Then | 1 request per USDC of cumulative volume |
| Open orders | 1000 by default |
| Plus | One more per $5M of volume |
| Capped at | 5000 |
What the address limit is really for
It ties your request allowance to your trading. An address that has traded nothing gets a starting allowance and no more; an address that trades gets room proportional to it.
The effect is that strategies which quote constantly and trade rarely run out of allowance, while strategies that actually trade never notice the limit exists. That is a design decision about what kind of activity the venue wants, expressed as a rate limit.
REST or WebSocket
WebSocket for anything continuous. Mid prices, book updates, your own fills. Polling these over REST burns weight to receive data that would be pushed to you for nothing.
REST for actions and one-offs. Placing an order, cancelling, changing leverage, fetching a historical snapshot once.
The most common beginner mistake in a first bot is polling l2Book in a loop. It works for a while, then the rate limiter arrives, and the fix is a subscription rather than a longer sleep.
What it costs
Nothing to use, and nothing extra to trade through. There is no API surcharge and no separate fee tier: an order placed by a bot pays exactly what an order placed by hand pays, at 0.045% taker or 0.015% maker at the entry tier.
That matters for anything running frequently, because the maker and taker gap compounds far faster on an automated strategy than on manual trading. Where the savings actually are.
Before you build
Read the order types first. Post-only, reduce-only, IOC and the trigger types are all available through the API, and using the right flag prevents whole categories of bug. The full list.
Test with small size on the real venue. A testnet tells you your code compiles. It does not tell you how a thin book behaves against your logic.
Decide what happens when your process dies. A bot that stops with resting orders on the book leaves those orders working. Decide deliberately whether that is what you want, and consider whether your strategy needs a cancel-on-disconnect discipline of its own.
Assume the ledger is public. Every fill your bot makes is visible to anyone, immediately, along with your positions. How public that actually is.
Where to go next
Getting started with the Python SDK, which is the shortest path from nothing to a placed order, and what to think about before running a bot at all.
Frequently asked questions
Do I need an API key?
Not in the usual sense. There is no key issued by a dashboard. Reading data needs nothing at all, and trading needs a signature from your wallet or from an API wallet you have approved.
Can an API wallet withdraw my funds?
No. It signs orders and other trading actions on behalf of the account. Withdrawals require a signature from the master wallet itself, which is what makes leaving a bot connected a tolerable risk.
What are the rate limits?
REST requests share a weight budget of 1200 per minute per IP, with different weights per endpoint. Separately, each address gets an allowance of one request per USDC of cumulative volume traded, on top of an initial buffer of 10,000.
How many open orders can I have?
A default of 1,000, plus one more for every 5 million USDC of volume, capped at 5,000 in total.
Should I reuse an API wallet address?
No. The documentation is explicit: once an agent is deregistered its used nonce state may be pruned, so a previously signed action could be replayed. Generate a new one instead.
REST or WebSocket?
WebSocket for anything you need continuously — prices, fills, book updates — because polling burns your weight budget for data that is pushed for free. REST for one-off actions and for placing orders.
Sources
- Hyperliquid docs: Nonces and API walletshyperliquid.gitbook.io
- Hyperliquid docs: Rate limits and user limitshyperliquid.gitbook.io
We link the primary source for every number on this page. If a figure here disagrees with the Hyperliquid documentation, the documentation is right and we want to know.