Feature Requests

Allow webhook payloads to update open bracket orders (SL/TP levels) without touching position size — a "reconcile target state with declared state" operation.
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.
1
Load More