An alert is not an order.

What TradingView actually sends

A webhook alert is an HTTP POST to a URL you supply, carrying a message body you write. Webhook notifications need a paid TradingView plan. That is the whole mechanism: TradingView does not hold a session with your broker for alerts, does not know whether an order filled, and does not find out what your account is holding.

For a strategy alert, the message can carry placeholders that TradingView fills in when the alert fires: {{strategy.order.action}} for buy or sell, {{ticker}} for the symbol, {{strategy.order.contracts}} for the quantity and {{strategy.market_position}} for where the strategy thinks it is afterwards. An indicator alert cannot use those, so each condition needs its own alert with fixed text.

Two consequences follow. The alert is only as good as the message you wrote, and once it is sent TradingView's part is over. Everything after that is the receiver's job.

What has to happen between the alert and Tradovate

A Tradovate account does not accept webhooks. Something has to receive the alert and hold an authenticated API session with Tradovate, then turn the message into an order.

Running that yourself means a server that is up through every session, OAuth and token renewal, reconnecting when the session drops, mapping symbols to contracts and logging every step so you can tell afterwards why a trade did or did not happen. None of it is exotic. All of it has to work at 3am on a rollover Thursday.

The TradingView webhook to broker page shows how Quanify's receiver handles each step. Automation, which routes TradingView and webhook signals to Tradovate and TopstepX, opens soon. Copy Trader is live today.

Contract names do not match

Most people chart a continuous contract such as NQ1!. Tradovate does not trade a continuous contract; it trades a specific month, which in November 2026 is the December contract, NQZ6. The {{ticker}} placeholder sends whatever the chart shows, so the receiver has to decide which real contract that means.

The awkward week is the roll. Volume moves to the next month before the old one expires, and a receiver that maps to the expiring month keeps trading a contract that is thinning out. The opposite mistake is charting a specific month and forgetting it: the alert keeps naming that month after everyone has moved on.

Check which contract your orders actually land on during roll week, every quarter. It is the easiest thing to get wrong and the easiest to check.

A strategy alert describes a position

A Pine strategy keeps its own idea of where it is. When it reverses from long one to short one, that is a single order for two contracts, and the alert reports an action of sell, two contracts, and a market position of short.

Read literally, "sell 2" is ambiguous: it could be a reverse or a new short of two. That is why the market position field matters. It tells the receiver the intended end state, so an exit and a reverse can be told apart.

The deeper problem is drift. If you close a position by hand, a broker rejects an order, or an alert is missed, the strategy on TradingView still thinks it holds what it held. Its next alert is based on a position your account does not have. Nothing on TradingView's side corrects that. The fix is operational: if you intervene manually, flatten the strategy's position fully or turn the strategy off until it is flat on the chart too.

The failures worth planning for

None of these are rare. Plan for each one before the strategy trades a funded account.

Duplicate alerts

The same alert delivered twice, or two alerts on the same chart firing on one bar. Without duplicate protection that is double size.

Late alerts

An alert that arrives well after the bar it describes. Quanify refuses a signal older than 30 seconds rather than filling it into a market that has moved.

Stacking

A strategy that pyramids, or a repeated signal, adding to a position you meant to hold once. The Allow 2+ entries guard is off by default and refuses a same-direction add.

Edited strategies

An alert keeps the version of the script and inputs it was created with. Change the strategy and the old alert keeps trading the old one until you recreate it.

Closed sessions

An alert that fires during the daily halt or outside the session. The broker rejects the order, and the strategy on TradingView assumes it filled.

One alert, several accounts

The quantity can come from the alert, or the strategy can carry a fixed contract size that overrides whatever the alert says. Fixed size is the safer default: a bug in your Pine sizing code cannot send twenty contracts.

Each linked account then applies its own whole-number multiplier, so one alert can trade 2 contracts on one account and 6 on another. There is no 0.5x, because contracts cannot be split.

The other shape is to route the alert to one Tradovate account and let Copy Trader repeat its fills on the rest, including TopstepX accounts as followers with market orders. Either way, size each account against its drawdown room, not its balance.

Test it before you trust it

A strategy that backtests well and an alert pipeline that works are two separate claims. Test the second one on its own.

1. 01Point it at a demo or paper account. Tradovate demo sub-accounts and Quanify's paper accounts both work, and the configuration carries over unchanged when you switch to funded.
2. 02Run it for a full week of sessions. Include an open, a close and at least one fast morning. A pipeline that works at noon has not been tested.
3. 03Compare the strategy's trade list with the account's fills. Every entry and exit on the chart should have a matching fill. A missing exit is the one that costs money.
4. 04Watch roll week. Confirm the contract month the orders land on before and after the roll.
5. 05Then attach funded accounts one at a time, each at the multiplier its drawdown room supports.