Skip to main content

Module stop

Module stop 

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 to takePrice). The connector sends no direction and does not guess one.
  • Lifetime. timeInForce = 3 is “algorithmic orders only”, and the docs give no lifetime for a conditional order. So only StopExpiry::GoodTillCancel is 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. EndOfDay and GoodTillDate are refused (unsupported_expiry) rather than sent into a field the docs reserve for another order type.
  • price. With executionStopLossType = 2 / executionTakeProfitType = 2 (limit execution) price is taken as the limit price of the order put at the trigger. With market execution (1) price is not sent.
  • Pairs. One request is one leg. The connector never sends stopPrice and takePrice together, so it never creates the TP+SL pair (list type 7) whose cancellation the docs do not describe.
  • Quantity. orderQuantity of 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.