Skip to main content
Order placement is a build, sign, save flow against the reactor contract’s EIP-712 domain. Cancellation is asynchronous and confirmed through order events, with the on-chain reactor as the source of truth. Prerequisites:
Programmatic order placement is governed by the separate API terms of service, not the web app’s in-app acceptance gate — see legal terms.
The client calls in the examples below use the wrapper surface described in the TypeScript bot client; you can also call the REST endpoints directly.

Place orders

1

Fetch the domain

The signing domain is environment-specific. Fetch it once with GET /signature/domain and cache it for the session.
verifyingContract is the reactor contract address used for signatures, and chainId identifies the Hedera network.
2

Build orders

Build orders with POST /orders/build:
The server assigns each order nonce and returns the serialized order struct to sign. Always sign the returned order object, not your original request object.
Quote the current book immediately before building a market order and continue only when fillable === true. For exact input, submit snappedInputAmount and suggestedOutputAmount; for exact output, submit suggestedInputAmount and snappedOutputAmount. Never use "1" as a market order’s outputAmount: that removes practical price protection from the signed order. Keep all integer quantities as strings, and do not cast nonces, deadlines, or raw token amounts to JavaScript numbers before signing. See Market quotes.
3

Sign orders

Sign only the EIP-712 order fields. Exclude metadata returned by the API.The signature wire format starts with a one-byte mode prefix:Do not strip the prefix. The reactor and backend use the prefix to choose the verifier.
For concrete ECDSA_SECP256K1 and ED25519 signing steps, see the TypeScript bot client signing behavior.
4

Save orders

Submit signed orders with POST /orders/save:
The response returns an orders array with saved order objects and meta.status populated. If ocoLinks were supplied, the response may also include an oco block with link status.

OCO orders

POST /orders/save also supports optional one-cancels-the-other (OCO) metadata through ocoLinks. OCO links are server-side transport metadata; they are not included in the EIP-712 digest and are not submitted to the reactor. Each link pairs two items in the same save request:
OCO pairs must share the same orderbookId and swapper, and currently only LIMIT orders are supported in OCO pairs.

Cancellations

Cancellation endpoints are asynchronous. A 202 Accepted response means the cancellation request was accepted; it does not mean the order is already canceled. Use the user-event WebSocket or GET /orders/:orderId/history to confirm the final ORDER_CANCELED event. POST /cancel accepts up to 500 order IDs per request. Split larger cancellation batches into multiple requests and reconcile each accepted order through the user-event stream or order history. The on-chain reactor remains the source of truth. Advanced clients can also submit on-chain cancellations directly to the reactor, then rely on indexer reconciliation.

Next steps

WebSockets

Track fills and cancellation finality on the user-event stream.

Limits and errors

Check order deadline bounds, batch size caps, and the production checklist.

TypeScript bot client

See the full flow — authenticate, build, sign, save, cancel — as working code.

Market data

Quote a market order first and feed the suggested amounts into the build call.