Take-Profit and Stop-Loss Ticks in Webhook JSON

A tick is the smallest quoted price increment defined for a contract. A point can contain several ticks, and the currency value of one tick varies by contract. Therefore, `sl: 20` expresses twenty increments away from an entry reference; it does not encode twenty dollars and does not imply the same risk on ES, MES, NQ, MNQ, or another future. Read the current exchange specification and the broker's actual destination contract before translating a strategy stop.

The JSON field conveys an instruction to the receiver, not a guarantee of a particular fill. Entry slippage can change the resulting protective prices if distances are anchored to the eventual entry, and broker capabilities can differ. HexTrade's public docs establish the tick unit and show example fields; use the connected route's current documentation and a controlled test to establish order linkage, modification, cancellation, and rejection behavior rather than filling those details with assumptions.

For an illustrative instrument with a 0.25 minimum price increment, a 4.00-point distance contains sixteen ticks because 4.00 divided by 0.25 equals 16. That arithmetic demonstrates the method; it does not establish a current specification for every future. Source tick size and tick value from the exchange's contract page and confirm the exact symbol at the broker. If the desired level is not aligned to a valid tick, define a rounding policy before encoding it.

Risk review must use the actual quantity that reaches the route. A dynamic `{{strategy.order.contracts}}` placeholder can differ across events, and a scale-in can change total open exposure even if each order has the same `sl`. `maxQty` is a documented hard cap per webhook request, which can catch an unexpectedly large value, but it does not calculate portfolio risk or account for other positions. Keep those calculations in an accountable risk process.

The example uses fixed protective distances because fixed inputs are easier to audit. Replace them only after calculating values for the exact destination contract. The chart can use a continuous or differently named symbol, but the payload must name what the connected account trades. If mapping is required, HexTrade documents `symbolOverride`; make that transformation explicit rather than allowing an accidental chart ticker to determine live routing.

`dryRun: true` asks HexTrade to return the planned trade without sending an order. It also does not update the documented in-memory cooldown and daily-trade counters. Use the result to verify account, symbol, side, quantity, and protective fields. Then remove dry mode only under a smallest-size live procedure. A parser success cannot confirm that the broker created protection or that a future fill will occur at the planned price.

Dynamic stops are useful for volatility or structure-based strategies, but each calculation must map to the destination contract. `syminfo.mintick` describes the chart context. If the chart symbol differs from the routed future, its minimum increment may not represent the destination. In that case, either chart the exact contract, supply a reviewed destination tick input, or calculate outside Pine under a documented mapping. Never silently combine a CFD chart's increment with a futures ticker.

Choose rounding based on protective intent. Rounding to nearest, floor, and ceiling can move the actual distance in different directions; the correct policy is a strategy and risk decision. Set minimum and maximum bounds and reject an invalid result instead of emitting malformed or dangerous JSON. Once the string is built, send dry-run examples at low, normal, and high volatility and parse the rendered body to ensure a number has not become `NaN`, `na`, or an empty value.

The distinction matters for stop and limit entries. A strategy can create an order several bars before its emulator fills, or the condition may never fill. An `alert()` emitted at creation can reach the external broker earlier than an order-fill event. Choose the desired model deliberately. Variables in `alert_message` are evaluated when the emulator executes the order, allowing the protective tick calculation to reflect Pine state at that simulated event.

The live route remains independent. A market can move between the TradingView event and the external broker response, and the destination may reject the order or protective instruction. Record both requested tick distances and the broker's resulting orders. Avoid enabling both an entry `alert()` and an order-fill event for the same external intent unless one is a non-trading diagnostic message that the receiver cannot interpret as an order.

Start with a hand-calculated case whose entry reference, tick size, target distance, stop distance, tick value, and quantity are written down. Compare Pine output with that worksheet. Then send a sanitized dry-run message and confirm the planned trade preserves the same units. Because dry run places no order, it cannot reveal broker-side bracket creation or slippage. The live gate is still necessary, but it should use the minimum approved exposure.

During the live gate, save requested values, receiver outcome, broker order identifiers where available, protective prices, quantities, statuses, and final fills or cancellations. Test what happens when the entry is rejected or only partly filled rather than assuming protection exists. If the route's order-management semantics are not documented, ask for current product guidance; do not publish a guessed claim based on one interface snapshot.