TradingView-to-Broker Symbol Overrides for Webhooks

The chart answers what data the strategy analyzed. The payload answers what instrument the receiver should route. Those can be intentionally different, but the difference must be explicit. HexTrade's symbol documentation gives the core examples: a Tradovate futures account wants a futures root such as `NQ`, while a TradeLocker CFD account may want `NAS100`. Sending the visually familiar chart text without checking the destination is a frequent route failure.

A mapping also changes risk. Full-size and micro futures, futures and CFDs, or two venue-specific products can have different contract values, sessions, liquidity, and margin. A string substitution is therefore not enough to prove economic equivalence. Review quantity and protective tick assumptions together with the symbol. If the mapping changes product class, require a separate strategy and risk approval rather than treating it as formatting.

A symbol is part of an instrument contract, not merely a display alias. `NQ` and `NAS100` may reference related market exposure in conversation, but they are not interchangeable order identifiers and do not establish identical economics. The broker account determines available products. Copy the instrument spelling and contract selection from that destination, then use the HexTrade documentation to express the route. Case, namespace, expiry, and root conventions can all matter.

Avoid building a universal dictionary from one successful trade. A broker can change listed names, a funded-account environment can expose a subset, and a crypto venue can use a special namespace. Store mappings with destination platform and account type, not just source ticker. Include an owner and review date. When the route changes, rerun dry mode and smallest-size validation rather than inheriting a mapping that happened to work elsewhere.

The mapping should be readable by a human. If a strategy analyzes a continuous chart but routes a broker root, retain a strategy label and note that identify the mapping version. Do not let a Pine placeholder automatically populate the destination when users can change the chart to another symbol. A fixed destination is safer for a single-instrument strategy; a multi-symbol strategy needs a reviewed lookup with a reject-by-default branch.

HexTrade's docs establish that the chart symbol can differ from the payload ticker and that `symbolOverride` is available. They do not justify every imagined source-to-destination pair. Test the exact account with `dryRun: true`, then verify a smallest-size live order. If a dry run accepts a string, the broker can still reject an unavailable or expired contract. Keep broker evidence as the final mapping test.

There is no universal roll date that fits every strategy and liquidity preference. Expiration, first notice, volume migration, broker availability, and account policy can matter by contract. CME educational material explains expiration and contract roll, while the exact product specification supplies current details. Assign an operator to review those sources and the destination account; do not automate a calendar substitution without a documented and tested policy.

A mapping update can leave split state. The visible Pine chart may change, an old TradingView alert snapshot may continue using previous inputs, and the receiver override may point elsewhere. Inventory all three before the change. Recreate alerts after chart or input updates, cancel or reconcile old-contract working orders through an authorized process, and test the new symbol with dry mode. Never assume replacing a string transfers open positions.

If HexTrade rejects before submission, inspect the documented route values and allowlist. A source ticker may be outside the approved destination set, or the override may contain a name that the payload contract does not accept. If HexTrade plans the request but the broker rejects it, inspect the account's listed product, expiry, session, and permissions. Do not repeatedly try nearby symbols in live mode; that is uncontrolled discovery with execution risk.

Silent-looking failures often come from observing the wrong account or expecting a fill from an order that remains working. Correlate strategy label, alert time, account, source and destination symbols, requested quantity, receiver result, and broker state. If the chart uses a CFD while the account trades a future, include that fact in the incident record. It changes both routing diagnosis and the risk review.

A useful matrix has source chart symbol, chart exchange, timeframe, mapping version, `ticker`, `symbolOverride`, allowlist, platform, account, expected destination instrument, expected quantity, and expected tick model. Add negative cases: an unsupported chart, typo, lowercase or uppercase mismatch where relevant, expired contract, and destination outside the allowlist. The route should reject unknown mappings rather than falling back to the source string.

Review the matrix whenever a broker, product class, contract, or Pine snapshot changes. Keep credentials and the private endpoint out of test artifacts. TradingView requires valid JSON for the JSON content type and restricts webhooks to secure public endpoint behavior, but transport success says nothing about symbol correctness. Close testing only when sender, receiver, and broker evidence all name the intended instrument.