Expand description
Stop orders: PlaceStopOrderRequest -> BCS conditional order (orderType = "5").
The mapping follows the current docs (POST /orders, checked 2026-10-19). What the docs do NOT say
is settled here in the safest way:
- Trigger direction. Not a field of the request. The broker decides it, from the side and the
kind (stop-loss of a SELL = price falls to
stopPrice, take-profit of a SELL = price rises totakePrice). The connector sends no direction and does not guess one. - Lifetime.
timeInForce = 3is “algorithmic orders only”, and the docs give no lifetime for a conditional order. So onlyStopExpiry::GoodTillCancelis accepted and NO time-in-force field is sent: the order lives as long as the broker’s default for conditional orders. If that is shorter than “until cancelled”, the stop disappears at the broker’s deadline: the live run must find out.EndOfDayandGoodTillDateare refused (unsupported_expiry) rather than sent into a field the docs reserve for another order type. price. WithexecutionStopLossType = 2/executionTakeProfitType = 2(limit execution)priceis taken as the limit price of the order put at the trigger. With market execution (1)priceis not sent.- Pairs. One request is one leg. The connector never sends
stopPriceandtakePricetogether, so it never creates the TP+SL pair (list type 7) whose cancellation the docs do not describe. - Quantity.
orderQuantityof a conditional order is sent like for plain orders (whole units).
Functions§
- build
- Wire body of a stop order. Everything that can be checked locally is checked before anything is sent or any quota is spent.