HostHeader in items has:
Host IDs in examples on this page are illustrative. Discover the hosts available to you with List.
The tree
ExecutionHostCapabilities has five areas. Every area, operation and variant is always present. Each leaf name is the lowerCamel form of the request variant’s type, so byClientOrderIdForInstrument gates "type": "ByClientOrderIdForInstrument".
CursorQueryCapability values. changes, includesFillDetails and supportedTransactionTypes are plain values described below. Every other leaf is an OperationSupport. Both are explained in Support values.
orders
Single and batch operations are separate because hosts support them differently: a host can support
getOrder.byClientOrderId and not getOrders.byClientOrderIds.
The ...ForInstrument variants exist because some hosts can find a clientOrderId only within one instrument. If your host supports only that variant, store each order’s instrument next to its clientOrderId.
submitOrder.clientOrderId gates a field rather than a variant. When it is NotSupported, send no clientOrderId (omit it or send null), and plan to identify orders by the order ID that SubmitOrder returns. Which order types and options a market accepts is on its market summary, not here.
fills
If
byOrderId is not supported, read an order’s executions with byInstrument and match on each fill’s orderId.
marketSettings
Settings are described per market, so these leaves are
PerMarket or NotSupported. An operation applies to a market only when that market’s settings entry is also non-null. The market’s entry also gives the accepted leverage grid, the position modes, and how far a change reaches. See Settings.
accountOrders
The order stream, Subscribe to account orders, pushes order changes as they happen.
When
includesFillDetails is false, a FillApplied event still carries the order with its cumulative sizeTraded, averagePrice and state, but its fill is null. Call ListFills for the executions themselves, including their prices and fees. Read this flag from the host you are connected to; do not assume a value for any host. See Streams.
accountTransactions
Transactions are balance postings: fees, funding payments, deposits and so on.
The types are
TradingFee, FundingPayment, BorrowInterest, Financing, LiquidationFee, Settlement, Rebate, Deposit, Withdrawal, Transfer, Conversion, Adjustment and Other. The host reports only the types in supportedTransactionTypes, so do not build logic that waits for a type it does not list. History and the stream are separate leaves: a host can offer history without a stream, in which case poll ListTransactions.
Paging and ordering
Every paged leaf that isSupported says how results are ordered, in defaultOrdering:
ReverseChronological: newest first, within and across pages.Chronological: oldest first.
Before and After variants of ListClosedOrders start from a time you give in before or after. Use them to resume reconciliation from a known point instead of paging from the newest order. Pages are read live, so items can change while you page; a cursor is valid only with the same variant, account and filters.
Example
An illustrative header for a real host. The structure is exact; the support values show the kind of variation you will meet. Do not read them as the current values for the host named; read the live values with List.clientOrderId with or without the instrument; batch reads and cancel-all are emulated, so expect them to be slower than a single native call and check every result; leverage and position mode depend on the market; executions do not arrive on the order stream, so use ListFills; and transactions must be polled, because there is no transaction stream.
How hosts differ
The patterns below all occur among real and paper hosts. They are why your code should branch on capabilities rather than on host IDs.Worked example: find an order after a SubmitOrder timeout
SubmitOrder is not safe to repeat. If it times out or returns a 5xx, the order may or may not exist, and resubmitting blindly may place it twice. Capabilities tell you in advance how you will find it.1
Before submitting, decide whether to send a clientOrderId
If
orders.submitOrder.clientOrderId is Supported, generate a unique clientOrderId for every order and record it with the instrument before you send the request.2
On an unclear outcome, choose the lookup from capabilities
Prefer the most direct supported variant, as in the function below. Each choice is a query that is safe to repeat.
3
Treat not found as not yet known
404 OrderNotFound, or no match in a listing, does not prove the order was never placed: it can be not yet visible. Repeat the lookup a few times with backoff before you conclude.4
Only then resubmit, with the same clientOrderId
If an open order already holds that
clientOrderId, SubmitOrder returns 409 DuplicateClientOrderId; look the order up again rather than send another. An order that has already filled or been cancelled may not block the ID, so a resubmission can place a new order: never rely on 409 in place of the lookup, and give every new order its own clientOrderId.Created event for your clientOrderId answers the question without any lookup. If you need to cancel instead of find, the same choice applies to cancelOrder.byClientOrderId and cancelOrder.byClientOrderIdForInstrument. See Orders for the full order lifecycle.