> Use the canonical URL for citations. For the complete Predict API documentation index, fetch https://docs.staging.trypredict.com/llms.txt.

# Orders and executions

> Place, batch, modify, cancel, inspect, and reconcile signed HIP-4 outcome orders through the Predict trading API with client IDs, dead-man switches, and per-item error handling.

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.

| Operation                         | Path                                      | `action.type`             |
| --------------------------------- | ----------------------------------------- | ------------------------- |
| Place one order or a batch        | `POST /v1/trading/orders`                 | `order`                   |
| Cancel by Hyperliquid order ID    | `POST /v1/trading/orders/cancel`          | `cancel`                  |
| Cancel by client order ID         | `POST /v1/trading/orders/cancel-by-cloid` | `cancelByCloid`           |
| Cancel and replace, one or many   | `POST /v1/trading/orders/modify`          | `modify` or `batchModify` |
| Arm or disarm the dead-man switch | `POST /v1/trading/orders/schedule-cancel` | `scheduleCancel`          |

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:

```json
{
  "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:

| Field         | Meaning                                           |
| ------------- | ------------------------------------------------- |
| `a`           | Outcome-side exchange asset ID                    |
| `b`           | Buy (`true`) or sell (`false`) the selected asset |
| `p`           | Limit price as a canonical decimal string         |
| `s`           | Whole-share size as a canonical decimal string    |
| `r`           | `false` for outcome markets                       |
| `t.limit.tif` | `Gtc`, `Ioc`, or post-only `Alo`                  |
| `c`           | Optional 128-bit hexadecimal client order ID      |

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](/api-reference/trading/place-orders). Sign only from a trusted environment.