Skip to main content
Complex orders extend simple limit and market orders with algorithmic execution logic. Each complex order is a parent that the Molecule engine decomposes into one or more child orders. Cancelling the parent propagates automatically to every child — you never need to track or cancel children individually. Complex orders use idempotency_key (not client_order_id) as the idempotency key, and the API enforces that the same key cannot be reused with a different request body.

Complex Order Types

ICEBERG

Slices a large order into smaller child orders. Only the current slice size is exposed to the market at any time, hiding the true total quantity from other participants.

PEG

Continuously tracks a reference price, adjusting the resting order as the market moves. Use this to maintain a position relative to the best bid, ask, or mid.

STOP

Remains passive until a specified trigger price is reached. When the market trades through the trigger, the engine submits a child order on your behalf.

TP_SL

Places a take-profit and stop-loss bracket around an existing position. Both legs are managed as children of a single parent; cancelling the parent removes both.

SMART_ROUTE

Routes a single order across multiple venues to achieve best overall execution. Requires generic_asset_id so the router can identify the same market across venues.

Creating a Complex Order

Submit a complex order using client.create_complex_order(**payload) (top-level shortcut) or client.complex_orders.create(**payload). Both call POST /v1/complex-orders. The type field selects the algorithm; the params object carries type-specific configuration.

ICEBERG Example

An ICEBERG order exposes only slice_qty contracts to the market at a time. Once a slice fills, the engine submits the next slice automatically until the full qty is complete.

STOP Example

A STOP order submits a child order only when the market price reaches trigger_price. The child order is placed at the price you specify.

Parameters

string
required
The complex order algorithm. One of ICEBERG, PEG, STOP, TP_SL, SMART_ROUTE.
string
required
The subaccount under which the order is placed.
integer
The venue-specific instrument. Required when routing.mode is DIRECT or when targeting a specific instrument.
integer
The cross-venue asset identifier. Required when routing.mode is BEST_PRICE, SPLIT, or SMART_ROUTE.
string
required
BUY or SELL.
string
YES or NO. Required on binary markets where the instrument is identified by outcome.
string
required
Total quantity to execute, as a decimal string (e.g. "1000").
string
Limit price for the order or its child orders, as a decimal string (e.g. "0.52"). Required for most types.
object
Type-specific configuration.
object
Routing configuration. Contains a mode field: DIRECT, BEST_PRICE, or SPLIT.
string
A client-supplied string used to deduplicate submissions. The same key with a different request body returns ConflictError (idempotency_conflict).

Idempotency

Complex orders use the idempotency_key field — not client_order_id — as the deduplication key. The SDK sends this value in the Idempotency-Key request header. If you retry a request with the same idempotency_key and an identical body, the API returns the original response. If the body differs, the API raises a ConflictError with error code idempotency_conflict.

Managing Complex Orders

Retrieve a Single Complex Order

Fetch the current state of a complex order — including its status and any child order references — using client.complex_orders.get(order_id).

List Complex Orders for a Subaccount

Retrieve all active and historical complex orders for a given subaccount.

Cancel a Complex Order

Cancel a single complex order by ID. Cancelling the parent automatically cancels all its outstanding child orders.

Cancel All Complex Orders

Cancel every open complex order for a subaccount in a single call.
Cancelling a parent complex order propagates to all child orders immediately. You do not need to track or cancel child order IDs individually.