Building With the Hyperliquid API
A practical map of the Info API, Exchange actions, signing, and the minimum architecture for a Hyperliquid application.
A Hyperliquid application usually needs two different capabilities: read market or account state and submit signed actions. Treating those as separate paths makes the API easier to reason about.
Read through the Info API
The Info API exposes data such as market metadata, order books, candles, open orders, fills, positions, and other account or market state. Many read requests use a typed JSON payload rather than a large collection of unrelated URL paths.
For production applications, builders should cache stable metadata and avoid repeatedly requesting data that changes rarely.
Write through signed Exchange actions
Placing orders, cancelling orders, transferring funds, and other account mutations require authenticated actions. Hyperliquid uses cryptographic signatures rather than a conventional server-issued username and password session.
Many applications use an API wallet, also called an agent wallet, so the user's main wallet does not need to sign every trading action. The agent has its own key and authorization relationship to the master account.
The minimum application architecture
A simple trading product may contain:
- a frontend for user intent
- a backend or local signer for controlled key handling
- Info API requests for state
- WebSocket subscriptions for live updates
- Exchange actions for orders and cancels
- local reconciliation so the product knows which requests became fills
Build around failure, not only the happy path
Professional integrations should explicitly handle rate limits, duplicate or stale nonces, network retries, partial fills, rejected orders, disconnects, and state reconciliation after downtime.
The exchange response to an order submission is not the same thing as a final trading outcome. A robust application continuously reconciles orders, fills, balances, and positions with authoritative Hyperliquid state.
Hyperliquid exposes relatively low-level market infrastructure. That is powerful for builders, but it means production reliability is partly the application's responsibility.
Sources
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/nonces-and-api-wallets