This API is separate from the legacy SaucerSwap REST API. The legacy REST API uses
x-api-key authentication. The V3 Orderbook API uses wallet challenge authentication and short-lived JWTs.Integration Flow
Authenticate first, then use testnet before moving the same flow to mainnet. Move to mainnet after your client handles authentication renewal, WebSocket reconnects, cancellation finality, and integer string handling correctly.
Environments
WebSocket streams use the same host with the
wss:// scheme.
Authentication
All protected endpoints require a JWT issued by the/auth flow. Attach the JWT to REST calls with:
Challenge request:
JWTs are short-lived. Re-authenticate before a long-running session expires or whenever a protected call returns
401.
Endpoint Summary
Market Discovery
UseGET /books to discover tradable orderbooks before building orders. Key market fields include token identifiers, market status, trading increments, and the current AMM-routing flag:
inputToken and outputToken when building orders. Use baseTokenDecimals and quoteTokenDecimals when converting between human-readable display amounts and raw token amounts. Keep the build, sign, and save path on raw token units. If isAMMEnabled is true, AMM liquidity can be routed into that book when an order request also opts into AMM-backed settlement.
Place Orders
Order placement is a build, sign, save flow:- Fetch the signing domain with
GET /signature/domain. - Build orders with
POST /orders/build. - Sign the returned order structs client-side.
- Save signed orders with
POST /orders/save.
1. Fetch the Domain
The signing domain is environment-specific. Fetch it once and cache it for the session.verifyingContract is the reactor contract address used for signatures, and chainId identifies the Hedera network.
2. Build Orders
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.
4. Save Orders
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 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:
orderbookId and swapper, and currently only LIMIT orders are supported in OCO pairs.
Policy Limits
The API applies these limits automatically:
If a requested deadline exceeds the max, the server may clamp the returned order deadline. Always sign the deadline in the built order response.
Cancellations
Cancellation endpoints are asynchronous. A202 Accepted response means the cancellation request was accepted; it does not mean the order is already cancelled.
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.
WebSockets
Both streams require a valid JWT in thetoken query parameter:
- Connect to the depth stream.
- Buffer diffs while fetching the REST depth snapshot.
- Apply buffered diffs after the snapshot.
- Continue applying live diffs.
Production Checklist
Before placing sustained mainnet flow, confirm your client can:- re-authenticate after
401responses - reconnect WebSockets with backoff
- rebuild local books from snapshot plus buffered diffs
- treat cancellation
202responses as acknowledgements, not final states - keep all
uint256values as strings through signing and saving - use the orderbook token decimals when converting raw amounts for display or order sizing
- store JWTs and private keys only in server-side secret storage
- monitor open order count, deadlines, and rate-limit responses
- reconcile user events with
GET /orders/:orderId/historyafter reconnects