Allow webhook payloads to update open bracket orders (SL/TP levels) without touching position size — a "reconcile target state with declared state" operation.
Eli Stair
Feature Request: quantityType: "no_op" — Enable Bracket Order Lifecycle Management without touching position state.
Goal: Allow webhook payloads to update open bracket orders (SL/TP levels) without touching position size/state — a "reconcile target state with declared state" operation. If flat, do not enter. If long/short, do not modify or exit.
Background
My algorithmic strategies ratchet stop-loss and take-profit levels mid-trade (trailing stops, profit-lock steps). The broker brackets placed at entry quickly diverge from the strategy's current target state. There's no way to resync them through the webhook without also changing position size, or risking spurious entry/exit when that is not the objective (or safe).
The existing cancel-and-replace pattern ("cancel": true + "action": "buy") does update brackets, but it's fundamentally unsafe when the account is flat: TradersPost has no way to distinguish "modify brackets on open position" from "open a new position," so a ratchet event on a flat account silently becomes an unsolicited buy order. This makes the mechanism undeployable in any live setup where fills can arrive asynchronously between alert bars.
Add a new quantityType value:
{
"action": "buy",
"cancel": true,
"quantityType": "no_op",
"takeProfit": { "limitPrice": 215.50 },
"stopLoss": { "type": "stop", "stopPrice": 198.75 }
}
Semantics: if quantityType is "no_op", skip all position-sizing logic and treat the payload as a bracket-only modify. Concretely:
If account is in position: cancel existing bracket orders, place new bracket orders at the supplied levels. No entry order issued.
If account is flat: discard the payload entirely (or optionally return a 4xx so the caller can observe the no-op). Do not open a position.
This is the minimal change that makes the cancel-and-replace pattern safe. The rest of the existing schema and routing logic is untouched — takeProfit, stopLoss, cancel, sentiment fields all behave as today.
Why this fits the existing model
quantityType already abstracts how quantity is determined (fixed_quantity, percent_of_position, etc.). no_op is a natural extension: it answers "how much to trade?" with "zero — this is a bracket-only operation." The flat-position guard then follows directly from the existing open-order-cancel semantics.
Our infrastructure context
We run a middleware redistributor between TradingView webhooks and TradersPost that classifies alert payloads by span_type (entry, exit, bracket_update, etc.) using fields in a telemetry block. The redistributor already tags ratchet events as span_type: "bracket_update" and stores a last-write-wins slot for downstream consumers. The Pine strategy computes new absolute SL/TP levels bar-by-bar. The only missing link is a TP-side mechanism to apply those levels safely — quantityType: "no_op" closes that gap without requiring any change to our middleware or Pine code, or replacing traderspost with a custom application.
Lindsey Starkweather
Design Considerations, for scalability:
- Add "action": "OCA" one-cancels-all and allow users to specify group name, followed by multiple sub-orders (ex. buy + sell, entry/exit ladders, etc.). My brokerage (IBKR) uses OCA "Group Name" to create standalone bracket orders without having to attach to a parent order. There's A LOT of potential here.
- Add a flag to "Ignore zero positions" (flat positions) or whatever label makes the most sense. Put this attribute in the strategy and allow signal override via webhook. A lot of potential here too.
- If "cancel": true then cancel all open orders for position before creating new orders (existing functionality).
- Add "action": "update" rather than a new quantityType. Figure out how to update a basic limit order via webhook first, then expand solution to bracket orders. If there are multiple open orders, the trader may need to pass the order id in the webhook or maybe throw an error? This is a can of worms, and we could probably workaround it using #1 and #3.
----------------------------------
New functionality:
A) Create standalone bracket orders and OCA order groups
B) Ignore signals for zero positions
C) Update any standing order (nice-to-have)
Existing functionality (no change):
D) Cancel all open orders for position and replace with new order(s)
E) Attach bracket order to parent order
OP and others can weigh in.