Order Routing

This is an old revision of the document!

Prerequisite: subscribe to the account first, and hold a Trading role. Orders into an unsubscribed account are rejected.

Prices and Volumes are Decimal Strings (e.g. “5”, “1.50”) — see Prices & Data Types.

Client Order Messages

Message	Purpose
OrderSubmit\|OrderSubmit	Place one or more orders into a single account+market.
OrderRevise\|OrderRevise	Change working orders (price, volume, max show…).
OrderPull\|OrderPull	Cancel working orders.
OrderBatch	Submit several `OrderSubmit`s, validated all-or-nothing (may span accounts/markets).
CreateUDS	Define a user-defined strategy (custom spread).

order_submit {
  account_id: "ACCT1"
  market_id:  "..."
  order_link: ORDER_LINK_NONE        // e.g. ORDER_LINK_OCO to pair orders
  manual_order_indicator: false
  orders {
    buy_sell:   BUY_SELL_BUY
    price_type: PRICE_TYPE_LIMIT
    time_type:  TIME_TYPE_NORMAL
    volume:      { value: "5" }
    limit_price: { value: "4200.50" }
    ClOrdId: "my-order-1"            // your id, echoed back as tag_cl_ord_id
  }
}

Multiple orders in one OrderSubmit share the same account and market.

Order types — price_type (PriceType) and time_type (TimeType):

Price type		Time in force
`MARKET`		`NORMAL`
`LIMIT`		`IMMEDIATE_AND_CANCEL` (IOC)
`STOP_MARKET`		`COMPLETE_VOLUME` (FOK)
`STOP_LIMIT`		`GOOD_TILL_CANCELLED` (GTC)
`FLATTEN`, `RFQ`, …		`MARKET_ON_OPEN` / `MARKET_ON_CLOSE`

Full lists in proto/t4/v2/common/enums.proto.

Address the target order by unique_id (from its OrderUpdate) or by your ClOrdId. In OrderRevise set only the fields you are changing.

Set margin_inquiry: true on a submitted Order to get a MarginInquiryResponse with pre-/post-order margin and impact — nothing is sent to the exchange.

Set user_id to route for another user. Requires the order-routing role and that the user is in your firm.

V2 delivers all order lifecycle events through one OrderUpdate message. Read update_type to know what it is:

`update_type`	Meaning
`SNAPSHOT`	Existing order sent on account subscribe.
`STATUS`	Working / revised / pulled / rejected state change.
`TRADE`	A fill occurred.
`TRADE_LEG`	A fill on a strategy leg.
`FAILED`	The request failed.

Key fields: status (OrderStatus: WORKING, FINISHED, REJECTED, HELD) · change (OrderChange: fine-grained lifecycle) · status_detail (human-readable reason) · current_volume / new_volume / working_volume / total_fill_volume (decimals) · current_limit_price / new_limit_price.

Correlate with unique_id, your tag_cl_ord_id (echo of ClOrdId), and tag_relation_id (batch/linked orders).

Each fill is also delivered as an OrderTrade (volume, price, residual_volume, exchange_trade_id, leg_index for strategies).

OrderBatch groups multiple OrderSubmits and validates them together:

All pass → OrderBatchAcknowledge (per submission: assigned unique_ids and echoed ClOrdIds), then normal per-order OrderUpdates follow.
Any fails → OrderBatchReject (nothing submitted; errors[] pinpoint the offending submission/order).

Set batch_id to correlate; it is echoed as tag_relation_id on the resulting updates.

Messages and every field: proto/t4/v2/orderrouting/orderrouting.proto. Enums: proto/t4/v2/common/enums.proto. See the Message Catalog.