Skip to main content
The SaucerSwap V3 Orderbook API is designed for programmatic trading clients, market makers, wallets, dashboards, analytics surfaces, and other integrations that need order placement, cancellation, account order state, and live orderbook data. The documentation is public. Protected API calls require wallet authentication, and production users should expect rate and service-protection limits. Teams planning sustained high-volume traffic should contact [email protected] so we can coordinate limits and support.
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:
The challenge and verify endpoints are the only unauthenticated calls: Challenge request:
Challenge response:
Verify request:
Verify response:
Supported account identifiers: JWTs are short-lived. Re-authenticate before a long-running session expires or whenever a protected call returns 401.
Never put a primary wallet private key in a bot process. Use a dedicated integration account, store secrets server-side, and start on testnet before placing mainnet orders.

Endpoint Summary

Market Discovery

Use GET /books to discover tradable orderbooks before building orders. Key market fields include token identifiers, market status, trading increments, and the current AMM-routing flag:
Additional price, volume, and timestamp fields may also be present. Use the returned EVM token addresses for 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:
  1. Fetch the signing domain with GET /signature/domain.
  2. Build orders with POST /orders/build.
  3. Sign the returned order structs client-side.
  4. 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

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.
Keep all integer quantities as strings. Do not cast nonces, deadlines, or raw token amounts to JavaScript numbers before signing.

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

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 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.

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. A 202 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 the token query parameter:
Treat WebSocket URLs as sensitive because they contain the JWT. Avoid logging full URLs in production. For reliable depth handling:
  1. Connect to the depth stream.
  2. Buffer diffs while fetching the REST depth snapshot.
  3. Apply buffered diffs after the snapshot.
  4. Continue applying live diffs.
Re-authenticate before each reconnect attempt. Active WebSocket connections are verified at handshake time; a connection can remain open after its original JWT expires.

Production Checklist

Before placing sustained mainnet flow, confirm your client can:
  • re-authenticate after 401 responses
  • reconnect WebSockets with backoff
  • rebuild local books from snapshot plus buffered diffs
  • treat cancellation 202 responses as acknowledgements, not final states
  • keep all uint256 values 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/history after reconnects

Error Format

Errors are returned as:
Common statuses:

TypeScript Client

For a server-side bot example, see TypeScript Bot Client.