Hyperliquid Exchange Endpoint Guide
The Exchange endpoint submits signed HyperCore actions such as orders, cancels, transfers, staking, vault operations, API-wallet approvals, and account configuration.
POST /exchange is Hyperliquid's action surface. A request contains the action payload, nonce, signature, and context such as a vault or subaccount address where applicable. The same endpoint carries many action types, so production clients should treat each action schema as a distinct typed command rather than building loosely structured JSON by hand.
Trading actions
Orders, cancellations, TWAPs, scheduled cancels, and related trading controls use the Exchange endpoint. Time-in-force values such as GTC, IOC, and ALO change the behavior of limit orders.
A client order ID can help reconcile local intent with exchange state.
Account and asset actions
The endpoint also includes spot transfers, generalized asset transfers between supported domains, withdrawals, staking operations, vault transfers, API-wallet approvals, builder-fee approvals, and account-abstraction configuration.
These are higher-authority operations than an ordinary order. Permission and signing policy should reflect that.
Subaccounts and vaults
Subaccounts and vaults do not have independent private keys in the normal sense. The master signer submits actions with the relevant target address in the request context.
If a system signs with the correct master key but omits or misroutes the target address, it can operate on the wrong account.
Expiry and dead-man controls
Some actions support expiresAfter, allowing stale requests to be rejected. The schedule-cancel action acts as a dead man's switch by scheduling cancellation of open orders unless refreshed or removed.
These controls are valuable for automated systems, but they consume rate-limit capacity under documented rules and need monitoring.
Error handling
HTTP success does not imply every order in a batch succeeded. Parse action-level statuses and errors. Reconcile the resulting order or position state before assuming the operation completed as intended.
Retries must be nonce-aware and idempotency-aware. A network timeout can mean “request failed” or “response was lost after acceptance.”