Why you get duplicate or repeated orders
One alert, two fills. Or one alert that somehow trades three times. It is one of the more unsettling things to see in a log, because the orders are real and the money is real. The good news is that duplicates almost always trace back to one of two causes, and both have a clean fix. The first lives on your side, in how your signals are being sent. The second lives in the signal itself.
Find which one you have before you change anything. The fix for one does nothing for the other.
Cause 1: more than one sender is firing
This is the one people miss. If the same alert produces the same order twice at the same instant, the most common reason is that two senders are alive at once and both reach Autoview.
On the legacy Chrome extension, that means more than one browser is running Autoview against the same TradingView account. Two laptops, or a laptop and a VPS, each with Autoview installed and logged in, each catching the alert and each executing it. Close one. Run a single instance and the doubling stops. People who lean on the extension usually keep it on a dedicated machine with one Google account precisely to avoid this, so nothing else picks up the same alert.
The modern webhook platform sidesteps the problem differently. It runs on our servers, around the clock, with no browser to duplicate. But the same logic still applies one level up: if two alerts, or two separate webhooks, are both pointed at the same account and both fire on the same condition, you get two orders. The duplicate can come from any sender. A TradingView alert, a TrendSpider alert, a script you wrote, even a webhook you forgot you set up months ago. Audit what is actually posting to your account and prune the ones you do not need.
Cause 2: the indicator repaints
The second cause is not Autoview at all. It is the alert. A repainting strategy on TradingView (or any charting source) redraws its signal as new price data arrives, so it can fire, un-fire, and fire again on the same setup. Each fire sends a fresh alert. Autoview receives honest, distinct alerts and does exactly what it is told: it trades each one.
Repainting gets fixed in the script, usually by having it wait for the bar to close before it fires. On the Autoview side, you can stop acting on the repeats. That is what dedupe is for.
The fix for repeats: the dedupe parameter
On the Chrome extension, Autoview reads a parameter called dedupe=. Its job is de-duplication. You hand it a value that uniquely tags the alert, and Autoview remembers the last value it saw for that alert. When a new alert arrives carrying the same dedupe= value as last time, Autoview ignores it and runs nothing. When the value is different, Autoview executes the commands and starts watching for the next value.
Use dedupe on the Chrome extension. That is where Autoview stores and compares the value. On the cloud webhook platform the parameter is accepted without an error but not compared, so a repeat still trades. If your alerts reach Autoview through a webhook, stop repeats at the source: prune duplicate senders (Cause 1) and fix the signal itself (Cause 2).
So a repainting strategy that fires the same setup three times in a row, all carrying the same tag, trades once. The two repeats are dropped on arrival.
Put dedupe= at the top of your alert, above the commands:
dedupe=<your-unique-value>command 1command 2
Order matters here. Keeping dedupe= first lets Autoview decide whether to proceed before it touches any of the trading commands below it. If the value is a repeat, the commands never run.
Where does the unique value come from? From the alert sender, the same way every dynamic value does. On TradingView you want dedupe={{time}}, the timestamp of the bar the alert fired on. That value stays the same across every repaint of the same bar, so the repeats collapse the way you want. dedupe={{timenow}} looks like the same kind of placeholder but does the opposite: it is the current clock time at the moment the alert fires, so every repeat gets a new value and none of them match, and nothing gets deduplicated. Both tokens are TradingView's, not Autoview's; Autoview just receives whatever string lands there. A Python script or another platform builds the same alert its own way and writes its own unique value into dedupe=. The rule is simple: same setup, same value; new setup, new value.
What dedupe does not do
Be honest with yourself about what this buys you. Dedupe does not remove repainting and it does not turn a false signal into a good one. It only stops you from trading the same false signal twice in a row. The underlying strategy is still the strategy.
If your strategy waits for the candle to close before it fires, false signals get rarer, and dedupe becomes a much sharper tool on top of an already steadier signal. If your strategy fires intrabar on every tick, dedupe will catch the back-to-back repeats but it will not save a setup that was noise to begin with. Fix the signal first. Use dedupe to clean up what is left.
The dedupe mechanism, defined precisely
Naming each piece separately makes it easier to reason about:
- The key. Whatever string you put in
dedupe=. Autoview treats it as an opaque tag, not a timestamp or an ID it interprets, so anything unique per setup works, not only TradingView's own placeholders. - The retention window. Exactly one value: the extension remembers only the last
dedupe=value it saw for that alert, not a history of recent values. A new value that happens to match one from several fires ago, not just the immediately preceding one, would still be treated as new and would execute. This is a single-slot comparison, not a rolling window. - The surface. Chrome extension only, per the code-level verification linked above (
worker.js, storage-backed, per-alert-id). The cloud webhook platform parsesdedupe=without error but does not compare it, so a repeat sent to a webhook still trades. - The failure mode. On the extension, a value collision means Autoview drops a fire it should have kept, if you reuse a
dedupe=value across genuinely different setups by mistake, since the single-slot design can't tell that case from an honest repeat. On the webhook platform, the failure mode is silent: nothing is deduplicated at all, and the parameter's presence gives no error or warning that it did nothing.
Stopping repeats on the webhook platform
On the webhook platform, duplicate protection lives earlier or later in the chain. Two places to use: TradingView's own alert carries a bar {{time}} value and, separately, delivery metadata your receiving logic can inspect if you're building a custom relay in front of Autoview; and once an order reaches the exchange, most venues assign or accept a client order ID you can inspect in your own records to reconcile "did this specific order already go in" independently of Autoview's log. Those are the tools for idempotency on the webhook platform.
Seeing it without risking an order
On the extension, you can watch dedupe's single-slot behavior with d=1 and no money at risk. Fire dedupe=test1 followed by a trading command with d=1, then fire the identical alert again: the second dry-run should log as ignored, not as a resolved dry-run command. Change only the dedupe= value on a third fire and it resolves again. That non-trading sequence demonstrates the same-value-drops, different-value-executes behavior described above without placing a single real order.
A quick way to tell the two apart
Open your Autoview log when a duplicate happens and look at the timing. Two orders at the exact same moment, identical down to the detail, point at Cause 1: something is sending twice. Two orders seconds or minutes apart, on the same setup, point at Cause 2: the indicator repainted and sent a second honest alert. The first is a sender problem you solve by running one instance or pruning a stray webhook. The second is a dedupe= problem.