Webhook → Leader → Copy Follower: A Reliable Trading Topology

A TradingView alert is a message, not a fill. Successful HTTP delivery proves only that an endpoint received a request. The endpoint must authenticate and validate it, resolve the intended strategy, account, contract, side, quantity, and risk policy, and then submit a leader order. That order can be rejected, remain working, fill in pieces, or never fill.

The copy stage begins at the supported fill boundary, not merely because the webhook was accepted. Each newly observed leader fill becomes a versioned copy event. The group calculates follower targets and submits separate requests. A follower result cannot be inferred from the webhook response or leader fill.

This topology limits ambiguity and over-copying. It also creates a clear audit chain: alert identity, validation decision, leader client correlation, leader order and fills, copy-event identity, follower decisions, follower broker outcomes, and reconciled positions. Every retry or manual recovery should attach to that chain.

TradingView documents webhook delivery behavior and cautions around sensitive credentials. Do not place broker passwords or secret API credentials in alert bodies. Use a hard-to-guess endpoint or signed authentication mechanism supported by your integration, TLS, and a server-side mapping from strategy identity to approved leader account.

Include a unique alert or intent ID, strategy ID, action, canonical symbol, contract selection rule, quantity mode, and event time. Reject missing, malformed, stale, or unsupported inputs before broker submission. Avoid free-form text parsing when a structured JSON payload can define the same intent unambiguously.

Keep risk controls server-side. The alert can request an action, but the service should enforce permitted account, symbol, maximum quantity, session policy, and kill switch from trusted configuration. Log a redacted hash or safe representation of the payload with the validation result.

TradingView documents webhook resubmission behavior in supported circumstances, so duplicate delivery must be expected. Store the intent ID with a durable processing state. If the same valid payload arrives again, return the prior result or a safe acknowledgement instead of creating another leader order.

Do not use only timestamp and symbol as an identity; two legitimate strategy actions can share them. Generate or carry a stable intent ID and attach a supported client correlation to the leader request. For fills, use the platform's stable order/fill identifiers plus incremental quantity. For follower requests, derive an idempotency key from copy event, follower account, and target version.

Idempotency does not mean replaying stale intent forever. Apply an age limit and compare the current target before executing queued work. If the leader has already exited, a delayed entry follower action should not suddenly become valid because a retry timer fired.

Select a leader whose contract, strategy permissions, and risk settings are appropriate even if no followers exist. The webhook handler should not inflate leader quantity to represent the group. Each account's quantity belongs in its own sizing policy; otherwise a follower configuration change can unintentionally alter leader risk.

Track partial fills and cancellations. If a three-contract leader order fills one and then cancels two, the copyable quantity is one under a fill-driven design. If that one contract later exits, the follower target changes based on the exit fill, not on the initial three-contract request.

A leader connection gap creates uncertainty. Pause new follower routing until missed events are recovered and the leader position is reconciled. Do not fabricate fill events from a displayed position difference without a documented recovery method, because manual trades and other strategies may share the account.

For each copy event, apply contract mapping, multiplier, fractional carry, integer rounding, maximum quantity, current-position limits, connection health, and account policy. The result is either a proposed request or an explained skip. Store the configuration version so a later multiplier change does not rewrite why an earlier decision occurred.

After submission, follow broker events through acknowledgement, working, partial fill, fill, cancel, reject, or unknown. A successful leader trade can coexist with any combination of these follower outcomes. Position drift is actual follower position minus the current intended follower target, not merely the difference between submitted quantities.

Manual follower trades complicate reconciliation. Decide whether they are prohibited operationally, detected and alerted, or incorporated through a deliberate position-based model. Never silently overwrite an unexplained manual position with an automatic correction.

A malformed or unauthenticated webhook should stop before any leader request. A leader reject should produce no fill-derived follower action. A missing leader feed can require group pause because copy events may be incomplete. A single follower reject can often pause that follower while healthy accounts remain visible, subject to the group's documented risk policy.

Timeouts require state lookup rather than blind replay. Rate-limit responses call for bounded backoff and capacity review. Unsupported symbols should fail closed. Authentication expiry should mark the affected connection unavailable. Use stable error classes for alerting while preserving the broker's exact response for diagnosis.

Provide manual controls for disabling a webhook strategy, pausing a group, pausing one follower, and initiating a separately confirmed flatten procedure. A flatten request also has independent outcomes per account, so track completion instead of assuming the button restored consistency.

Start with one leader and one low-risk follower. Send one valid intent and verify the exact audit chain. Resend the same intent ID and confirm it does not create a second leader order. Exercise a payload that fails a server-side cap and verify that it stops before the broker.

Next observe a partial leader fill if it occurs naturally in a safe environment, or use an approved simulation method. Verify that only filled quantity affects follower target. Test a follower skipped by a local policy gate, a connector reconnect, and an unknown-outcome recovery without deliberately violating broker rules.

Finish with an entry and exit, then compare actual positions at both accounts. Define pass criteria in advance: no duplicate intent, no uncorrelated order, no unexplained position drift, and complete timestamps and identifiers. Increase followers and cadence gradually while monitoring delivery failures, queue age, broker errors, and reconciliation lag.