Can Pine Script Execute Trades? What It Does and Doesn't Do

Short answer: no. Pine Script can detect setups, calculate position sizes, and simulate entries on your TradingView chart. But it can't send an order to your broker. The "trades" you see in TradingView's Strategy Tester are simulated fills against historical or live price data. They exist on the chart and nowhere else.

That distinction trips up many traders who've just built their first profitable strategy. You see green on the equity curve, you want it running live, and you assume there's a button somewhere that connects it to your brokerage account. There isn't, at least not in the way you'd expect.

The rest of this article covers why Pine Script can't execute real trades, what your actual options are for bridging that gap, and where things go wrong once you do.

What happens when Pine Script "executes" a trade

When your strategy calls strategy.entry("Long", strategy.long), TradingView does a few things internally. It checks the order against your strategy settings (pyramiding, position sizing, slippage model), simulates a fill at the next available price, and logs the trade in the Strategy Tester tab.

What it doesn't do: talk to any broker. No HTTP request goes out. No order hits any order book. Pine Script runs in TradingView's cloud sandbox, which has no network access.

You can confirm this yourself: try calling any external API from Pine Script. It won't work. Pine Script cannot make HTTP requests by design.

This is the core Pine Script limitation that every new algo trader eventually runs into. The language was built for charting and backtesting. It's very good at that. But execution was never part of the spec.

Four ways to get from Pine Script to a real broker

You have four options. They vary in cost, complexity, and the extent to which you keep your Pine Script workflow.

TradingView's built-in broker panel. TradingView has native integrations with a handful of brokers. If yours is on the list, you can enable autotrading directly from the chart. Your strategy signals fire, and TradingView sends the orders to the broker without any external tool. The upside is obvious: zero setup.

The downside is that the broker list is short, mostly US stock brokers and a few forex and crypto platforms. Most prop firm accounts aren't supported. And you get limited control over how orders are handled, with no custom SL logic and no signal filtering. For someone just testing whether automation works at all, it's a reasonable starting point. For anything beyond that, you'll outgrow it fast.

Webhook bridge. This is where most traders end up. You keep your strategy in Pine Script, set up a TradingView alert with a webhook URL, and a bridge service translates the alert into a broker order. The alert fires as an HTTP POST to the bridge's server, which parses the payload and sends the instruction to an Expert Advisor (or equivalent) on your broker's terminal.

The advantage is that you don't rewrite any Pine Script. You keep your existing indicators, your backtest history, and your TradingView workflow. The disadvantage is that you're adding a multi-stage pipeline between your signal and your fill, and each stage can fail in ways you might not expect. More on that below.

Rewriting the strategy in your broker's native language. For MetaTrader users, this means converting Pine Script to MQL5. You rebuild the entire strategy from scratch in a different language, with different syntax, different data access patterns, and different execution semantics. The result runs natively on your broker's terminal with no external dependencies. But the cost is significant: MQL5 is harder to learn than Pine Script, the debugging experience is worse, and you lose TradingView's charting and backtesting tools. Most retail traders who start down this path abandon it within a week.

Manual execution. You watch TradingView alerts on your phone and place trades by hand. Cost: zero. Speed: however fast you can open the app and tap the right buttons. Error rate: whatever your attention span allows at 3 a.m.

This works for very low-frequency strategies, a few trades per week. For anything faster, you're the bottleneck.

For the majority of traders reading this, the webhook bridge is the right answer. You already have a working strategy in Pine Script. You probably spent weeks or months refining it. TradingView webhook automation lets you keep all of that work and add execution on top.

If you want Pine Script to execute trades on a live account, this is the most practical path. The question is what happens inside that pipeline.

How Pine Script webhook execution actually works

The signal pipeline from Pine Script to your broker has four stages.

Stage 1: Pine Script fires. Your strategy detects a setup and calls strategy.entry() or strategy.close(). At this point, TradingView internally simulates the order.

Stage 2: TradingView sends a webhook. If you've configured an alert on that strategy with a webhook URL, TradingView sends an HTTP POST containing whatever you put in the alert_message parameter. This requires a paid TradingView plan (Essential or higher). Free plans don't support webhooks.

Stage 3: The bridge server receives and translates. The bridge parses the incoming JSON or text payload, maps it to the correct instrument and order type on your broker, and pushes the instruction downstream.

Stage 4: The EA executes. An Expert Advisor (or equivalent connector) running on your broker's terminal picks up the instruction and places the actual order.

Each of these stages is a potential failure point. And the failures aren't always obvious. A webhook might arrive, but the EA might be disconnected. The market might be closed. Or the order fills at a price your strategy didn't expect.

If you don't have visibility into what happened at each stage, you're left guessing why your broker's trade log doesn't match your TradingView chart.

The gap between alerts automation and actual trade execution is where most automation setups break down. Not because the concept is wrong, but because the implementation details are harder than they look.

What breaks between Pine Script and your broker

Three problems repeatedly occur when you start running Pine Script signals through a webhook bridge. None of them is obvious until they cost you money.

Ghost positions. The alert_message parameter fires the instant strategy.entry() is called. Not when the fill is confirmed. During fast-moving markets, the simulated fill on TradingView might not match reality. Or the order might be rejected entirely.

But the webhook already fired. Your bridge already told the EA to open a position. Now you have a trade on your broker that doesn't exist on your chart.

On XAUUSD during a news spike, that phantom position can move 30+ points against you before you notice it. On a $2K account, that's a real hit.

Signal reordering. Your strategy goes from long to short. Two signals fire within milliseconds: close the long, open the short. But webhooks are HTTP requests over the internet. They don't arrive in a predictable sequence.

If "open short" arrives at the bridge before "close long," the EA opens the short first, a brief mid-reversal state with both positions on the account. When "close long" arrives a moment later, the EA looks for a long to close and finds two positions tagged with its magic number. If its close logic picks the most recently opened one, it closes the freshly opened short. The long stays. You end up holding the position your strategy was trying to exit, with no indication anything went wrong.

SL/TP drift. Your strategy says: enter long at 43,300, stop loss at 43,250 (50 points below). The webhook sends the SL as a distance from entry: 50 points. But you fill at 43,302 due to slippage. The EA calculates 43,302 minus 50 and places the stop at 43,252, not at 43,250 where your strategy logic intended.

Two points of drift. That's above your intended support level. If price touches 43,251, your strategy thinks you're still in the trade. Your broker already stopped you out.

These aren't edge cases. They happen on ordinary trading days with ordinary spreads. The reason most traders don't notice is that they have no way to compare what TradingView sent versus what their broker did.

Why this matters more on prop firm accounts

Everything above applies to any live account. But on a prop firm evaluation, the margin for error shrinks to almost nothing.

Consider a $50K FTMO evaluation with a 5% daily drawdown limit. That gives you $2,500 of room before you fail the day. A single ghost position on US30 at 1 lot moving 50 points against you eats $500 of that budget, 20% of your daily limit, on a trade that shouldn't exist. You paid $300 just to attempt the evaluation.

Prop firm risk management often focuses on position sizing and strategy rules. But execution fidelity is part of the risk equation, too. If your bridge misorders a reversal signal and you end up holding the position your strategy was trying to exit, that's a daily drawdown violation waiting to happen. It wasn't your strategy that failed. It was the infrastructure between your strategy and your broker.

Most traders with TradingView strategy automation on funded accounts discover this the hard way: they fail an evaluation, review their trades, and realize the problem wasn't the entry logic or the exit logic. It was the bridge.

Executing Pine Script trades with FillEdge

FillEdge is a webhook bridge built specifically to solve the execution problems described above.

Ghost position prevention. FillEdge generates signals only after a fill is confirmed on TradingView. If the fill doesn't happen, no webhook fires. Your broker doesn't open a position that shouldn't exist. This is an architectural difference: most bridges rely on alert_message, which fires at order call time. FillEdge uses a different signal generation method that waits for fill confirmation.

Signal ordering. On reversals, FillEdge's server ensures the close signal is always processed before the open signal, regardless of network timing. You won't end up holding the position your strategy was trying to exit.

Correct SL/TP placement. FillEdge supports two modes, and you choose per strategy. Exact-price mode places the stop at the literal price your script calculated, so 43,250 stays 43,250 regardless of fill slippage. Distance mode preserves the offset from actual entry for ATR-based and volatility-scaled strategies. The stop matches your logic either way.

Strategy isolation. If you're running multiple strategies on the same account, each one operates independently. A close signal from your trend-following strategy won't touch a position opened by your mean-reversion strategy. They're completely separated.

Signal-to-trade matching. Every signal carries a status badge: ✓MATCHED means TradingView and your broker agree, 👻CAUGHT means a ghost was intercepted, 🔀REORDERED means a reversal was sequenced correctly. You don't scan the log hoping to spot a mismatch. The badge surfaces it.

FillEdge also monitors the pipeline on its own. Synthetic test signals travel the full path on a regular cadence, without placing a trade. If any leg stops responding, you get an email or Telegram alert within minutes.

The setup takes about 15 minutes. You add a template to your Pine Script (no rewriting), install an EA on your broker's terminal, and point a TradingView alert at your FillEdge webhook URL.

So can Pine Script execute trades? Not on its own. But with the right bridge, every signal your strategy generates can become a real order on your broker, with the execution fidelity to match.

FAQ

Can Pine Script send orders directly to a broker?

No. Pine Script runs inside TradingView's cloud sandbox, which has no outbound network access. When your strategy calls strategy.entry(), TradingView simulates the fill internally but doesn't contact any broker. To get signals to a broker, you need an external path: TradingView's built-in broker panel (limited broker list), a webhook bridge, or a full rewrite in your broker's native language.

What is a ghost position in TradingView automation?

A ghost position is a trade that exists on your broker account but not on your TradingView chart. It happens because the alert_message parameter fires the instant strategy.entry() is called, before the fill is confirmed. If the market moves and the fill doesn't happen (or happens at a very different price), the webhook has already told your broker to open a position. The result is a real trade with real risk that your strategy never intended to take.

How fast do TradingView webhook signals reach my broker?

The total time depends on three legs: TradingView processing the alert and sending the HTTP POST (typically under 1 second), the bridge server receiving and translating the signal (varies by provider), and the EA on your broker's terminal placing the order (depends on broker latency). End-to-end, most webhook-based setups land somewhere between 200ms and 2 seconds under normal conditions. Latency spikes during high-volatility events like NFP or FOMC releases.