# Hyperliquid Python SDK The official Python client for signing and sending orders on one perp DEX. *https://cryptomarkets.tools/tools/hyperliquid-python-sdk · Crypto Trading Bots & Execution SDKs* ## Facts ### At a glance | Field | Value | | --- | --- | | Vendor | Hyperliquid | | Category | Crypto Trading Bots & Execution SDKs | | Job | execution_sdk | | Website | https://github.com/hyperliquid-dex/hyperliquid-python-sdk | | Pricing model | open-source | | Free tier | true | | Open source | true | | Licence | MIT | | Self-hosted | true | | KYC required | false | | Tested hands-on | false | | Last updated | 2026-09-19 | ### Coverage | Field | Value | | --- | --- | | Asset classes | spot, perpetuals | | Chains | none | | Venues | dex, derivatives | | Data latency | realtime | | Platforms | library | | AI features | none | ### Interfaces | Field | Value | | --- | --- | | API | false | | Webhooks | false | | Scripting | Python | | MCP server | false | | Export | json | ### Capabilities Yes: live_trading, paper_trading, derivatives_analytics No: charting, screening, backtesting, automation, portfolio_tracking, exchange_import, tax_reporting, alerts, news, onchain_data, wallet_tracking *Verified: pricing 2026-09-19; capabilities 2026-09-19; coverage 2026-09-19.* ## What it is The first-party Python client for Hyperliquid, and the entry point for most code written against that venue. Three modules and nothing else: `Info` for reads, `Exchange` for anything that needs a signature, and `WebsocketManager` for subscriptions. It is a single-venue SDK, and that is a different product from a multi-venue client, not a smaller one. A unified library such as [CCXT](https://cryptomarkets.tools/tools/ccxt) buys you portability at the cost of the lowest common denominator — it exposes the operations every venue has, in the shape they all share. This exposes what Hyperliquid has, including the parts nothing else has: vault transfers, sub-accounts, builder fees, TWAP slice fills, staking and delegation, multi-sig conversion, spot and perp asset deploys, even validator registration and jailing. `Exchange` carries over fifty methods and only about a dozen of them are order entry. If your strategy needs any of the rest, the unified layer cannot reach it; if your strategy needs a second venue tomorrow, this cannot reach that. `Info` is the half people underestimate. Forty-five read methods, none of which needs a key, and most of which take an arbitrary address — the README's own first example fetches the account state of a wallet that is not yours. Funding history, per-user funding history, L2 book snapshots, candles, asset contexts, portfolio, fee tier, vault equities and the account's own rate-limit status are all one unauthenticated POST away. Liveness, in dates: last commit on `master` 4 June 2026, release 0.24.0 published to PyPI the same day at 19:47 UTC, and no commit on that branch in the 90 days since. Earlier releases ran at roughly two-month intervals — 0.23.0 in April, 0.22.0 in February, 0.21.0 in November 2025. The licence is MIT from `LICENSE.md`, "Copyright (c) 2024 Hyperliquid Labs Pte. Ltd.". ## Pricing Free, MIT, nothing to buy. The costs are the venue's — Hyperliquid's own maker and taker fees and its funding payments — and the SDK adds none of its own. It carries no referral arrangement and no default builder address; the builder-fee mechanism is exposed as `approve_builder_fee` and an example, for people building on top of Hyperliquid who want to charge their own users, not as something charged to you. ## Data & coverage Hyperliquid perpetuals and Hyperliquid spot, and nothing else — that is the whole of the coverage question for a single-venue client. Market data comes from the same API as orders, so there is no separate feed to subscribe to and no history archive: `candles_snapshot` and `funding_history` take a start and end time and return what the venue serves. Three endpoints are built in as constants: mainnet at `api.hyperliquid.xyz`, testnet at `api.hyperliquid-testnet.xyz`, and `localhost:3001` for a local node. Switching between them is a different URL passed to the same constructor, which is why the testnet path is a genuine rehearsal rather than a simulation — the same code, the same signing, the same API, different money. ## Integrations **The agent wallet is the integration story.** `approve_agent()` returns a freshly generated key that is authorised to act for your account, and the repository's own example documents the limit in plain words: the agent cannot transfer or withdraw funds. That key is what belongs on the machine running the bot — the docstring even suggests running the approval step elsewhere, or signing it from a wallet app instead of putting the main private key into Python at all. Named agents created in the front end persist across sessions. Everything else is Python-side. The dependencies are `eth-account` and `eth-utils` for signing, `msgpack` for action encoding, `requests` and `websocket-client` for transport. There is no MCP server, no CLI and no notification layer. ## Limitations **One venue.** Hyperliquid works, or nothing works. There is no abstraction to swap out, and there is no cross-venue anything — no consolidated book, no hedge on another exchange, no failover. That is the correct trade for a strategy that exists because of Hyperliquid's order book, and the wrong one for anything portable. **No client-side rate limiting and no retries.** `api.py` is forty lines: a `requests.Session`, one POST method, and an exception mapper that raises `ClientError` on 4xx and `ServerError` on 5xx. The `timeout` argument defaults to `None`, so a request that hangs hangs forever unless you pass a value. Everything a production bot needs around an HTTP call — backoff, jitter, a request budget, a circuit breaker — is absent by design, and `Info.user_rate_limit` exists precisely because you are expected to manage it. **No orders over the websocket.** `WebsocketManager` subscribes and unsubscribes; order entry is REST only. **Three and a half months without a commit, against a venue that ships.** Hyperliquid is not a static API, and the SDK is not archived, but 4 June 2026 is the last thing in the log as of 19 September. Check the repository before assuming a recently added venue feature is reachable from here. **Development pins Python 3.10 exactly** — runtime supports 3.9 and up, but contributing requires that version and Poetry v1, which the README documents as a known annoyance. **It is a client, not a bot.** No scheduler, no strategy, no position sizing, no persistence and no backtester. Everything that makes automation automation is yours. ## Alternatives [CCXT](https://cryptomarkets.tools/tools/ccxt) reaches Hyperliquid too, through the same unified method names it uses for a hundred other venues, and is the right answer the moment there is a second venue. What it cannot reach is the venue-specific half of this SDK — vaults, sub-accounts, staking, deploys — and it adds a one-basis-point builder fee on Hyperliquid by default that you switch off in code. [ccapi](https://cryptomarkets.tools/tools/ccapi) is the same choice again for people who need C++ latency; it supports Hyperliquid execution, but addresses instruments by numeric asset id and needs secp256k1 and msgpack linked in. If what you want is a bot rather than a client, [Passivbot](https://cryptomarkets.tools/tools/passivbot) and [Hummingbot](https://cryptomarkets.tools/tools/hummingbot) both trade Hyperliquid and both bring the scheduling, sizing and risk machinery this deliberately does not. The rest of the [trading bots and execution SDKs](https://cryptomarkets.tools/categories/trading-bots) listing sets out where the line falls. ## FAQ ### Does using this SDK mean handing over my main private key? It does not have to. `Exchange.approve_agent()` mints an agent key, and the repository's own example states that the agent has no permission to transfer or withdraw funds. You set the main wallet's public address as `account_address` and the agent's private key as `secret_key`, so the key on the trading box signs orders and nothing else. ### Can I try it without real money? Yes. `constants.TESTNET_API_URL` points at the testnet API and the examples use it by default; `LOCAL_API_URL` targets a node on localhost. No account application, no KYC step and no exchange-issued key are involved in either case. ### Is this SDK still maintained? The last commit on `master` is 4 June 2026 and version 0.24.0 went to PyPI the same day, so nothing has landed in the three and a half months to 19 September 2026. Releases before that came at roughly two-month intervals. ### Does it handle rate limits or retries for me? No. Every call is a `requests` POST with no retry and no client-side pacing, and the timeout defaults to `None` unless you pass one. Backoff, retry and a request budget are yours to write around it. ## Also worth comparing - [ccapi](https://cryptomarkets.tools/tools/ccapi.md) — Header-only C++ market data and execution for 30 venues, on a Bloomberg-shaped API. - [CCXT](https://cryptomarkets.tools/tools/ccxt.md) — One MIT client for 104 crypto exchanges, 76 of them over websocket. - [CoinAPI EMS Trading API](https://cryptomarkets.tools/tools/coinapi-ems.md) — One order model over 26 exchange destinations, TWAP and VWAP, priced per account-hour. - [dYdX v4 Clients](https://cryptomarkets.tools/tools/dydx-v4-clients.md) — Four language clients for one perp DEX, under a licence that is not the one on the badge. - [GoCryptoTrader](https://cryptomarkets.tools/tools/gocryptotrader.md) — A Go trading engine for 22 exchanges that has never cut a release or a tag. - [Hummingbot](https://cryptomarkets.tools/tools/hummingbot.md) — Apache-2.0 Python framework for running market-making bots on CEXs and DEXs.