Route One TradingView Alert to Multiple Accounts

This two-stage design gives each responsibility one owner. TradingView and the webhook decide whether an order intent reaches the master. Copy trading begins from the master fill, not merely from the incoming alert. That distinction prevents a rejected master order from being described as a successful multi-account signal and creates a concrete reference event for followers. It also means a webhook dry run cannot test follower execution because dry mode places no master order or fill.

Every follower remains an independent trading account. A 1.0 multiplier matches master size according to the documented copy setting, 0.5 halves it, and 2.0 doubles it, but account capital, contract availability, permissions, prop-firm policy, margin, and broker state can still differ. Treat fan-out as several execution outcomes sharing one source event, not as one atomic order guaranteed to succeed everywhere.

An account array seems convenient but hides hard questions. If three orders succeed and two time out, what HTTP status should the receiver return? A qualifying 5xx could make TradingView resend the entire message up to three times, potentially repeating successful accounts. A 2xx could hide failed followers. A single master event followed by independently tracked follower attempts provides a clearer identity and failure boundary, even though it still requires monitoring.

It also keeps account configuration out of Pine. The strategy author should not need to republish and recreate a TradingView alert whenever a follower is added, paused, or resized. HexTrade documents named groups that can be activated, deactivated, edited, and deleted while connected follower accounts remain managed in the dashboard. Use that control plane rather than embedding changing account topology into alert text.

Master selection determines the event source. Use an account whose instrument, size, session, and strategy behavior can be observed directly. A master should not also receive a second copy of the same TradingView alert through another route. Name the group by strategy, environment, and risk tier so operators can distinguish it from a similar test group. Add a description that states the intended master symbol and ownership without including credentials.

Review followers individually. A multiplier is not a universal risk conversion: rounding, minimum contract size, product differences, current positions, and account rules can change the result. HexTrade's copy docs warn that a high multiplier on a funded account can breach limits. Confirm each firm's current permission for automation or copy trading through its first-party rules, and do not assume that technical support by a platform means the account program allows the practice.

Start with the master event's worst planned quantity and protective distance. Translate that exposure to each follower's exact destination product and account rules. A 0.5 multiplier on one master contract cannot literally place half of a futures contract, so observed rounding or minimum behavior must be established through current product documentation or testing rather than assumed. If a safe nonzero quantity cannot be represented, exclude that follower or redesign the master sizing.

Cross-platform groups add another review layer. HexTrade documents support among ProjectX, Tradovate, NinjaTrader, Rithmic, and Volumetrica, but platform support does not imply identical order semantics, symbol catalogs, latency, or rejection behavior. Keep symbol mappings and contract selection explicit. Test each distinct platform path separately before activating them together, and use lower initial exposure on the most constrained account rather than scaling from the most permissive one.

Partial failure is normal enough to design for. One follower can have stale authorization, another can reject the symbol, and a third can fill while the master remains open. An automatic rollback is not generally equivalent to reversing the original trade because prices move and exits can fail too. The operational goal is a known exposure map and a defined decision owner, not a fiction that the fan-out was atomic.

TradingView retries are the wrong recovery layer for follower problems. The sender knows only its HTTP delivery to the webhook route and can resend a qualifying 5xx up to three times. It has no safe knowledge of which followers acted. Keep the master webhook idempotent, correlate the master fill to follower attempts, and use group deactivation to stop new copying while investigating. Preserve broker evidence before closing or flattening under the account's risk procedure.

Begin with valid JSON and `dryRun: true` to validate the singular master route. Remove dry mode only for a smallest-size master test and confirm the broker fill. Next, activate one supported follower with the lowest practical exposure. Verify actual size and symbol, then deactivate and review. Add each platform path separately. This sequence makes an error attributable; enabling ten followers at once turns one mapping defect into a portfolio incident.

Write stop conditions: wrong account, wrong contract, unexpected multiplier result, unexplained latency, missing follower evidence, duplicate, broker rejection rate above policy, or any unknown state. Deactivate the group and pause the source alert when a threshold is crossed. HexTrade documents group statistics and P&L in the group view, but broker accounts remain the execution source of truth. Periodically reconcile both and review firm rules for freshness.