Why Blocking Repeat Trades Can Break TradingView Strategies

Two Buy alerts reach a trading account within seconds. A risk-control rule rejects the second because there is already a Buy position. That sounds reassuring until the blocked order turns out to be the second leg of a carefully designed strategy. Preventing repeat trades is not always the same as preventing duplicate webhook deliveries.

The real question is not whether two messages share a symbol and direction. It is whether they represent one instruction delivered twice or two instructions generated intentionally. A trade connector should not confuse those cases.

There are three different problems, not one

Webhook redelivery means one TradingView event reaches the receiving endpoint more than once. TradingView explicitly documents a retry when the receiver responds with HTTP 500–599, except 504: another attempt follows after five seconds, with up to three retries. One trigger can therefore produce as many as four deliveries. This is a transport issue, not pyramiding. See TradingView's webhook resubmission policy.

Multiple alert events are different. A Pine Script strategy may generate an alert() event and a simulated order-fill event. TradingView allows both event types in one strategy alert. A script may also make multiple intended entries as market conditions change. The official alert documentation explains that distinction.

Multiple broker records are different again. Two fills, two orders and two independently managed positions are not interchangeable descriptions. Before calling something a duplicate, establish exactly what was submitted and what was filled.

What competitors actually mean by protection

There is nothing inherently wrong with a protective rule when a trader chooses it knowingly. The trouble starts when a position limit is presented as though it could reliably identify an accidental webhook duplicate.

Pyramiding, averaging and martingale are not delivery errors

A strategy that adds to a position may send several Buy instructions at different times or prices. Pyramiding increases exposure through successive entries. Averaging changes the blended entry price. Martingale-style systems may increase size after losses - a particularly aggressive risk choice, but still a trading rule rather than a webhook malfunction. Whether any of these approaches is sensible belongs to strategy design and risk management, not to a duplicate-message filter.

Imagine a deliberate first Buy of one contract and a second Buy of one contract after a defined price move. A filter that allows only one Buy per direction does not repair the strategy. It silently turns a two-entry model into a one-entry model. The resulting live trades no longer follow the rules the trader tested.

The ATP example: two entries with different jobs

The ATP Premium Indicator workflow makes the distinction concrete. It can separate a trade into Long Entry 1 and Long Entry 2, each with its own identifier and exit logic. The first leg may use a fixed Stop Loss and Take Profit. The second may remain open as a runner managed by a trailing stop. Both alerts can refer to the same symbol, carry the same Buy direction and arrive close together.

Deleting the second Buy would destroy the runner leg. It would also make the later second-leg exit meaningless. The ATP Premium alert configuration guide documents the separate entry IDs, position sizes and trailing-stop workflow.

The destination account still matters: a hedging account may maintain separate positions, while a netting account can combine their exposure. Those broker rules must be respected; they are not grounds for discarding a valid second instruction. See the netting and hedging explanation.

How AlgoWay approaches incoming TradingView alerts

AlgoWay treats each valid alert as a trading instruction, rather than automatically rejecting it because another signal uses the same instrument and direction. For recognized TradingView sources, incoming requests are queued and acknowledged with HTTP 200 after successful enqueueing. Jobs for a given webhook are processed sequentially. Sequential processing does not rewrite strategy rules.

HTTP 200 means the request was accepted into the processing queue; it does not mean the broker filled the order. Nor does serialization alone prove that a repeated delivery can never execute twice. AlgoWay does not claim that two identical messages automatically carry different intentions, or that a position-side filter is a universal solution.

When two orders really are unexpected

Check the TradingView alert history, the AlgoWay Webhook Logs and the destination's order history for the same time window. Did TradingView create two events? Did one event reach the connector twice? Did one accepted instruction produce more than one execution record? The answer determines where to investigate; guessing from two Buy labels does not.

The companion guide, TradingView Duplicate Alerts: Why Orders Fire Twice, walks through that diagnosis. A genuine transport retry deserves transport-level investigation. An accidental extra alert deserves a corrected alert configuration. An intentional second leg deserves to be executed.

A connector is not the author of the trading strategy. Its job is to carry out the instructions the trader defined, while making their delivery and execution traceable. Calling every repeated Buy a duplicate may produce a cleaner log. It can also produce the wrong trade.