Pine Script Webhook JSON Templates for Futures

A useful template is deliberately boring. Stable keys make failures easy to compare, while TradingView placeholders supply values that truly change at alert time. HexTrade documents lowercase platform slugs, an account ID copied from Accounts, a destination instrument, quantity, and a buy or sell instruction. The chart can generate the decision, but the payload must describe the instrument understood by the connected broker. Do not infer the destination from a chart label when the account trades a different naming convention.

TradingView determines the request content type from the final alert message. A syntactically valid JSON message is sent as `application/json`; anything else is sent as `text/plain`. That distinction is operational, not cosmetic, because a JSON-only receiver can reject an otherwise sensible-looking message. Validate the rendered alert, not merely the Pine source string. Quotes introduced by dynamic text, missing commas, and unresolved assumptions about numeric formatting can all change the document that actually leaves TradingView.

Paste the template into the TradingView alert Message field after selecting the intended strategy condition. The documented strategy placeholders resolve the simulated order action and contracts at the event. Quoting those placeholders preserves valid JSON whether the rendered value is text or a numeric-looking string; the downstream contract can interpret quantity according to its documented schema. Set `ticker` to the symbol the connected account trades rather than assuming the chart's full symbol is accepted by the broker.

Use a test account or `dryRun` before removing the validation flag. HexTrade documents that `dryRun: true` returns the planned trade without sending an order and without advancing its in-memory cooldown or daily-trade counters. A successful dry run therefore verifies parsing and planning, not live authorization, exchange hours, margin, prop-firm policy, or fill behavior. Preserve that distinction in your test notes so a clean payload test is not mistaken for end-to-end execution proof.

Dynamic construction is useful when the message includes values that cannot be represented by alert-dialog placeholders alone. It is also easier to break. Pine does not provide a dedicated JSON serializer, so your script owns commas, quotes, escaping, boolean literals, and conversion of `na` values. Keep free-form user text out of the payload unless you also control escaping. A strategy name with an unexpected quote can invalidate an entire message even though every trading field is correct.

The example emits a compact object only when a confirmed crossover occurs. It uses a literal destination and a calculated quantity, then adds `dryRun` during commissioning. It is an educational pattern, not a complete strategy: the signal and sizing rules must be independently tested. If you instead customize strategy order-fill messages through the `alert_message` parameter, put `{{strategy.order.alert_message}}` in the alert dialog so TradingView sends that generated string when the broker emulator fills the simulated order.

Tick semantics make a payload portable in shape but not in economic effect. Different futures contracts have different tick sizes and tick values, and the same tick count can represent materially different price distance and money exposure. Verify the current contract specification from the exchange and the exact contract selected at the broker. Then calculate risk using actual quantity rather than copying a protective count from another symbol or from a full-size contract to its micro counterpart.

Keep the payload explicit during review. A reviewer should be able to see the route, instrument, size, and tick distances without reverse-engineering a compressed Pine expression. `maxQty` can place a documented hard cap on size, while `allowedSymbols` can restrict instruments. Those controls reduce configuration risk but do not replace strategy-side sizing, broker limits, or account-level risk rules. A protective request can still be rejected, unsupported, or behave differently across execution rails.

An order can be created by Pine before the broker emulator fills it. TradingView's order-fill alert exists at that emulated execution moment and can carry a per-order dynamic `alert_message`. That is often a cleaner trigger for a strategy whose external route is intended to follow simulated fills. By contrast, `alert()` can describe indicator conditions, warnings, or pre-order logic and can create fully dynamic strings, but it cannot directly fire in response to an emulator fill that occurs after the script hands the order over.

`alertcondition()` serves a different use case. It defines selectable triggers in indicators, requires a constant message at compile time, and relies on placeholders for changing values. It has no effect as an alert trigger in strategies. Choose the event primitive first, then choose a JSON construction technique. Trying to repair the wrong event model with payload fields usually produces timing confusion, repeated messages, or an external order that does not correspond to the intended strategy transition.

Begin with deterministic examples. Trigger one long, one short, one exit, one unexpected quantity, and one disallowed symbol. Confirm that malformed or unsafe messages fail visibly rather than being silently coerced. Keep the TradingView alert active and remember that changing the chart, script, or inputs does not update an existing server-side alert snapshot. Recreate it deliberately, then record the new version in `strategyName`, `alertName`, `note`, or another documented label.

TradingView webhooks require two-factor authentication and only target ports 80 or 443. The receiver must answer within three seconds or TradingView cancels the request. These transport facts should shape testing: inspect the Webhook status column in the alert log and avoid endpoints that perform slow work before acknowledging safely. If a private HexTrade URL leaks, regenerate it. Never post the URL or a credential-bearing message in chat while asking for help.