Hyperliquid API for Traders: Building Custom Bots, Webhooks, and Algorithmic Strategies

A trader running algorithmic strategies across multiple markets faces a recurring technical problem: how to integrate execution, risk management, and market data collection without relying on centralized infrastructure or incurring gas fees for each order. Traditional decentralized exchanges route trades through automated market makers (AMMs), which charge slippage and lack the order-matching mechanics familiar to professional traders. Hyperliquid solves this by offering a purpose-built Layer 1 blockchain with a fully on-chain central limit order book (CLOB), enabling sub-second execution times and zero trading fees while exposing that functionality through REST and WebSocket APIs designed for programmatic access.

Building a trading bot on Hyperliquid requires understanding both the API surface and the underlying blockchain characteristics that make this high-performance DEX distinct from both traditional exchanges and AMM-based DeFi protocols. The platform’s theoretical throughput of 200,000 orders per second, combined with 0.07-second execution latency, creates opportunities for strategies that would be impractical on slower networks. However, the technical details matter: authentication flows, rate limiting, order state management, and websocket subscription patterns determine whether a bot runs reliably or fails under load. This article covers the practical mechanics of integrating with Hyperliquid’s API and the architectural decisions that shape successful automated trading systems.

Authentication and account setup for Hyperliquid API access

Hyperliquid allows email-based account creation without mandatory KYC for basic trading, which simplifies onboarding but requires careful key management for API access. The platform does not use traditional usernames and passwords for API calls. Instead, traders generate an agent address and private key through the official UI, which then signs all requests. This design leverages Hyperliquid’s blockchain architecture: every API call is cryptographically signed, and the signature is verified on-chain before execution. Unlike centralized exchanges where API keys grant limited permissions, Hyperliquid signatures prove authorization through the wallet itself.

The signing process uses standard elliptic curve cryptography. A trader’s private key signs a message containing the action (such as „create order“), relevant parameters (asset, quantity, price), and a timestamp. The signature, along with the plaintext parameters, is sent to the API endpoint. Hyperliquid verifies the signature matches the agent address, confirming that the request originated from the wallet owner. This approach eliminates the need for API key rotation or revocation at the platform level—if a key is compromised, the trader’s primary recourse is to stop using that key immediately, since the blockchain will continue accepting requests signed by it.

Best practices for managing signing keys include storing them separately from trading logic, using hardware wallets or key management systems for production accounts, and never exposing the private key in version control, environment variables, or logging. Many developers use a dedicated signing service or sidecar process that handles key material, accepting unsigned requests and returning signed payloads without exposing the underlying key. For smaller operations, environment variables with restricted file permissions may be acceptable, provided the development and production systems are properly isolated.

The agent address is the public identifier used in all API calls. It is derived from the private key and registered on-chain when first used. From the trader’s perspective, this address appears in order confirmations, balance lookups, and all query responses. Monitoring which agent address is making which request becomes important when scaling to multiple bots or strategies—each should use its own agent address so that blame and debugging can be accurately traced. Hyperliquid’s API documentation provides code examples in Python, JavaScript, and Rust, with libraries handling the signing ceremony, but understanding the underlying cryptographic flow prevents misconfigurations.

REST API endpoints and order lifecycle management

Hyperliquid exposes a REST API with endpoints for placing orders, canceling orders, querying balances, retrieving order history, and accessing market data. The order placement endpoint is the most frequently called; it accepts parameters including asset (the perpetual or spot symbol), whether the order is a buy or sell, the limit price, and the size in base currency. Unlike AMM-based protocols, where a trader simply submits a swap and receives whatever liquidity is available, Hyperliquid’s order-matching engine processes limit orders against existing orders in the book. An order may be partially filled, fully filled, or remain open until canceled or the session expires.

Rate limiting enforces a maximum of 100 requests per second per agent address on the API layer itself, with an additional block-level limit to prevent spam. For a single-threaded bot making one order per second, this is rarely a constraint. However, bots that check open orders, retrieve account state, and query market data in tight loops can easily exceed the limit if not designed carefully. The typical solution is request batching and caching. Instead of checking the latest order status every 100 milliseconds, a bot should cache the last update and only refresh when necessary—for instance, when a websocket notification indicates a fill. This reduces API calls while keeping the bot responsive.

The order lifecycle begins when a request is signed and submitted. Hyperliquid returns an order ID immediately, but the order does not actually exist in the book until the block containing the order is finalized. This introduces a window of a few hundred milliseconds where the bot has an order ID but no guarantee that the order is live. Race conditions can occur if a bot cancels or modifies an order before the original transaction is included in a block. The safest pattern is to wait for confirmation before taking action based on an order ID, using either websocket notifications or periodic polling to verify state.

Cancellation is similarly asynchronous. A cancel request is signed and submitted, but the order remains in the book until the block containing the cancellation is finalized. If a bot tries to cancel and immediately place a new order in response, the old order may still exist when the new order is matched, creating unexpected partial fills. Experienced developers build in explicit wait logic or use websocket updates to confirm cancellation before proceeding. The cost of these delays is typically measured in milliseconds, which is acceptable for most strategies but critical to understand when latency-sensitive logic is involved.

WebSocket subscriptions for real-time data and event streaming

The WebSocket API on Hyperliquid provides real-time updates for account activity, order fills, and market data without the polling overhead of repeated REST requests. A bot connects to the websocket endpoint, authenticates once with a signed message, and then subscribes to channels such as „order_updates“ for fills and „candles“ for price data. Unlike REST, where each request requires a new signature, websocket authentication happens once at connection time, reducing computational overhead and latency.

Subscription parameters determine what data flows to the client. A bot monitoring a single perpetual might subscribe to order updates and the latest trades on that asset. A market-making bot might subscribe to candles at multiple intervals, order book snapshots, and order updates across a portfolio of assets. The key challenge is handling connection instability: websockets can be dropped by network interruptions, firewalls, or server restarts. A production bot must implement reconnection logic with exponential backoff, replaying subscriptions after reconnection and reconciling any events that may have been missed during the downtime.

Message ordering on the websocket is guaranteed—updates are sent in the order they occur—but a bot should not assume it receives every message. Network buffering, client-side processing delays, or server-side queuing can cause a message to be lost if the connection drops. Therefore, critical state such as account balance and open orders should be synchronized by making an HTTP request to query the current state, not inferred from the last message received. Websocket updates are best used to trigger these synchronization checks rather than as the sole source of truth.

The structure of websocket messages varies by subscription type. Order update messages typically include the order ID, new status (open, filled, canceled), fill quantity, and fill price. Candle messages contain OHLCV data at the requested interval. Trade messages include the price, size, and timestamp of each matched order. A well-designed bot parses these messages into internal data structures (such as fill events or candle objects) and processes them asynchronously, ensuring that message handling does not block other critical operations like risk checks or position monitoring.

Building a simple market-making strategy on Hyperliquid

Market making is a natural fit for Hyperliquid because the zero-fee structure and order-matching mechanics eliminate much of the friction that makes market making expensive on other platforms. A basic market-making bot subscribes to the latest trades and mid-price for an asset, then continuously cancels and replaces standing buy and sell orders at a fixed spread around the mid-price. If the asset is trading at $100, the bot might place a buy order at $99.90 and a sell order at $100.10, earning the 20-cent spread on each fill.

The implementation requires a few core loops. First, a data collection loop fetches the latest price from the websocket candles or trade stream and maintains a moving average or exponential smoothing to estimate fair value. Second, an order management loop checks the current mid-price against the last deployed orders. If the price has moved significantly, the bot cancels the stale orders and places new ones centered on the new mid-price. Third, a position monitoring loop tracks realized profit from fills and checks that inventory is balanced (roughly equal long and short exposure). If inventory drifts, the bot adjusts spreads to incentivize a return toward equilibrium.

A key parameter is the refresh rate. Canceling and replacing orders too frequently increases API load and risks missing opportunities. Too infrequently, and stale orders will cause losses as the market moves. A typical schedule is to refresh every few seconds or when the price moves by more than a threshold (such as 0.5% from the bid-ask midpoint where the last orders were placed). Because Hyperliquid’s order matching is on-chain, there is no need to worry about sub-millisecond latency races—the bot can safely refresh on a 1-10 second cadence without being out-competed.

Risk management in market making centers on inventory limits and drawdown controls. The bot should refuse to place new orders if inventory has exceeded a threshold, forcing liquidation toward a balanced position. It should also track realized losses and halt trading if daily losses exceed a preset limit. These checks must happen in the order loop before submitting new orders, not after. Hyperliquid also supports up to 50x leverage on perpetuals, which amplifies both profits and losses; a position that would be healthy at 2x leverage can be wiped out at 20x due to a brief spike in volatility. Responsible leverage use requires understanding the liquidation price and stress-testing the strategy against historical volatility.

Handling order fills, partial fills, and edge cases

Orders on Hyperliquid can be filled partially, fully, or not at all. A 100-unit limit order placed at the market might be filled with 30 units immediately and 70 units later when additional volume appears on the opposite side. A bot must track partial fills and manage position size based on actual fills, not submitted quantities. The order_updates websocket message indicates the fill quantity and price, allowing the bot to update its position accounting in real-time.

The complications arise at the boundaries. What if the bot has placed a buy order for 100 units, received a partial fill of 50 units, and then the strategy decides to cancel the remainder? The bot must send a cancel request with the original order ID. If the cancel is too slow, the remaining 50 units may fill before the cancellation is processed, and the bot will hold 100 units instead of 50. This is not a bug in Hyperliquid; it is the inherent nature of asynchronous order management. The mitigation is to wait for the cancel confirmation or to re-query the order state before taking actions based on the expected position.

Post-only orders are supported on Hyperliquid and are useful for market makers who want to add liquidity without consuming it. A post-only order is rejected if it would immediately match an existing order in the book. This prevents accidental taker fees (where they exist on other exchanges) and simplifies accounting—a post-only order that is accepted is guaranteed to have provided liquidity. However, Hyperliquid’s zero-fee model means post-only is a liquidity signal rather than a fee optimization, though the order-matching semantics remain useful for controlling behavior.

Slippage is less of a concern on Hyperliquid than on AMM-based DEXs because limit orders can be sized flexibly and the order book is transparent. A bot can place a market order (limit order at the best ask or bid) with high confidence in the worst-case price. However, if the order is large relative to available liquidity, it will be partially filled at the best prices and the remainder will execute at worse prices as the book is walked. Simulating order fills based on the current book state is a useful sanity check before deploying large orders.

Rate limiting, throughput optimization, and scaling considerations

Hyperliquid imposes a 100 requests-per-second limit per agent address, which accommodates most single bots but becomes a bottleneck when running multiple strategies simultaneously or when a bot queries market data frequently. The denominator of „per agent address“ is important: using multiple agent addresses allows a trader to partition their operations and effectively multiply the available rate limit. A high-frequency bot managing 10 strategies can use 10 agent addresses, each with its own 100 req/s budget, for a total of 1000 req/s across all bots.

API efficiency matters. Instead of querying account balance separately from open orders, use a single endpoint that returns both. Instead of polling for order status every 50 milliseconds, subscribe to order updates on the websocket. Instead of making a request for every individual fill, batch queries where possible. Most efficient bots use a combination: REST for infrequent state snapshots (account balance, open positions) and websockets for real-time events (fills, price updates). This reduces API load by an order of magnitude compared to a naive polling approach.

The 200,000 orders-per-second theoretical throughput is a platform-level capacity, not a per-user guarantee. In practice, a single bot pushing orders at the rate limit will share platform resources with all other traders. Latency is typically sub-100 milliseconds from submission to execution, but this can degrade during periods of extreme volume or network congestion. A bot should not assume that every order submitted will be executed within a predictable latency; it should instead build queuing and retry logic that accounts for variable execution times.

Backpressure handling is a subtle but critical consideration. If a bot submits orders faster than they are being matched and canceled, the number of open orders grows, and subsequent queries become slower. A production bot monitors the open order count and throttles new submissions if the count exceeds a threshold. This prevents cascading delays where the bot becomes stuck waiting for slow queries while missing trading opportunities. Simple implementations use a sliding window counter; more sophisticated ones prioritize critical operations (cancellations, risk checks) over secondary operations (new orders).

Testing, monitoring, and debugging trading bots on Hyperliquid

Hyperliquid provides a testnet environment running the same code and API as mainnet, with test tokens for free. A bot should be thoroughly tested on testnet before deploying real capital. Testnet allows a developer to verify the signing mechanics, test order placement and cancellation, confirm that websocket subscriptions work, and stress-test the bot’s handling of multiple simultaneous fills. Because testnet uses the same order-matching mechanics as mainnet, the behavior is representative.

Logging is crucial for debugging production issues. A bot should log every API request and response, noting the timestamp, parameters, and result. Order-related logs should include the order ID, asset, side, size, price, and status. Position and profit-loss logs should be written periodically (every minute or every 10 fills) so that an issue can be reproduced retroactively. When an unexpected loss occurs, high-quality logs allow the developer to trace the sequence of events and identify whether the bot behaved correctly or whether a bug caused the loss.

Monitoring should include alerting on key metrics: the number of open orders, the latest fill price versus expected price, the account balance, and any API errors. If the number of open orders suddenly spikes, that suggests the bot is failing to cancel orders efficiently and may be running out of margin. If the latest fill price is significantly worse than expected, that may indicate a problem with the order book state. API errors should trigger alerts immediately, since a persistent error might mean the bot is unable to execute while exposure is building.

Backtesting trading strategies before deploying them to live trading is a standard risk management practice. A simple backtest loads historical price data (available from public sources or APIs), simulates order placement and cancellation, and tracks profit and loss. Because Hyperliquid’s order-matching semantics are deterministic, backtests on historical data should be reasonably predictive of live behavior. However, backtests assume perfect information (the order book at each timestamp) that may not match reality (partial fills, latency, slippage during execution). Treat backtest results as an optimistic estimate and allocate only a fraction of the strategy’s theoretical capital in live trading until it has proven profitable on real data.

Advanced patterns: grid trading, arbitrage, and flash orders

Grid trading is a strategy that places multiple buy and sell orders at regular intervals above and below the current price, capturing profit as the price oscillates within the grid. On Hyperliquid, grid trading is straightforward because order placement is fast and free. A bot might place 10 buy orders spaced $1 apart below the current price and 10 sell orders above. If the price drops, the lower buy orders fill, establishing long positions. If the price rises, the sell orders fill, closing the positions at a profit. As the price oscillates, the bot continuously replaces orders to stay centered on the current price.

Spot-futures arbitrage exploits price differences between the spot market and perpetual futures. If perpetuals are trading above the spot price, a bot can buy spot and short perpetuals, capturing the difference when the futures price converges to spot at expiration. Hyperliquid supports both spot and perpetual trading on the same platform with zero fees, making arbitrage more profitable than on systems where fees and friction make small spreads uneconomical. The key challenge is managing execution risk: the bot must buy spot and short futures nearly simultaneously, or risk being exposed to price movement in between.

Flash orders or batch orders allow a bot to submit multiple orders in a single transaction, useful for placing grid positions or hedges atomically. Some DEXs support this via smart contracts; on Hyperliquid, it is approximated by submitting orders in rapid succession via the REST API. While not truly atomic, the latency is low enough that race conditions are rare. This technique is useful when deploying a market-making bot and wanting to establish an initial set of buy and sell orders before the strategy starts executing.

All of these strategies profit from Hyperliquid’s speed, zero fees, and order-matching transparency. However, they still require proper capital management, risk controls, and testing. A strategy that works in a quiet market may fail during high volatility. A bot that assumes 50 units will fill in a single trade may experience multiple partial fills, requiring state management that accounts for that reality. The API provides the tools; the trader provides the discipline.