Orders and executions

Signed writes go to Predict, one path per operation. You sign the Hyperliquid action yourself and Predict forwards the envelope unchanged, so the body below is the venue’s shape rather than this API’s.

An action posted to the wrong path is a 400 and never reaches Hyperliquid — the path and the signed action.type have to agree. Reads stay where they were: Hyperliquid /info for venue-native state, the Predict REST API for normalized orders, fills, and positions.

The request body

Every trading path takes the standard Hyperliquid /exchange envelope:

{
  "action": { "type": "order", "orders": [], "grouping": "na" },
  "nonce": 1712345678901,
  "signature": { "r": "0x…", "s": "0x…", "v": 28 },
  "vaultAddress": "0x…",
  "expiresAfter": 1712345700000
}

vaultAddress and expiresAfter are optional and forwarded when present. So is every other key, including ones Hyperliquid adds after this page was written.

Each order contains:

Hyperliquid does not provide separate market-order or fill-or-kill actions for HIP-4. A marketable IOC limit gives immediate-or-cancel behavior. Bound its price to cap slippage.

Idempotency and reconciliation

Generate a unique client order ID before signing and persist it with your local intent. After a timeout, query orderStatus by that ID before retrying. Reusing the same intent ID lets you distinguish an accepted order from a transport failure without guessing.

For a safe first-order flow:

1. Submit with a unique c value.
2. Inspect status and the matching element in response.data.statuses.
3. Confirm through orderStatus, openOrders, orderUpdates, or userFills.
4. Cancel only that client order ID during cleanup.

HTTP 200 can contain failure

Order and cancel actions return per-item statuses. A response can have top-level status: "ok" while an item contains { "error": "…" }. Batched pre-validation may return one error for the entire batch. Handle both shapes.

Cancel all open orders

There is no immediate one-field cancel-all action. Read openOrders, group the returned IDs with their asset IDs, then send a batched cancel. For automated strategies also maintain scheduleCancel; its time must be at least five seconds ahead, and Hyperliquid limits triggers to ten per UTC day.

What Predict answers with

A forwarded call answers with Hyperliquid’s status and body, unchanged. A rejected action is a 200 carrying {"status": "err", …}: it consumed its nonce on chain, so it is an answer rather than a failure.

Predict’s own refusals use the usual error envelope. A 400 means the action does not belong on that path or the envelope is not signed. A 429 means either that you are over your share of a busy egress address or that Hyperliquid has rate limited it; both carry Retry-After. A 503 means this deployment cannot forward writes.

Predict never retries a signed write, because a Hyperliquid action has no idempotency key and a resend can duplicate one whose answer was lost. If a call fails without an answer, reconcile by client order ID before sending anything again.

Start with Place orders. Sign only from a trusted environment.