Pine Script can't make HTTP requests. Here's what you do instead

You wrote a Pine Script strategy. It works on TradingView. Now you want it to send a signal to your broker, log a trade to a Google Sheet, or ping a Discord bot when a setup fires. So you go looking for something like http.get() or fetch() in Pine Script.

It doesn't exist.

Pine Script cannot make HTTP requests. No outbound calls, no socket connections, no REST API access. The language has no networking primitives at all. And this isn't a bug or an oversight. TradingView made a deliberate architectural decision here, and once you understand why, the workaround becomes obvious.

Why Pine Script can't make outbound calls

TradingView runs millions of Pine Script instances simultaneously across its servers. Every chart with a script on it is a running process. If any of those scripts could hit arbitrary URLs, TradingView would be operating the world's largest unsupervised botnet. The security and infrastructure implications are obvious.

So Pine Script runs in a sandbox. Your code can read price data, calculate indicators, call strategy.entry(), and draw on the chart. It cannot reach outside the TradingView environment. The request.security() function sometimes confuses people because it sounds like a network call, but it only pulls data from other TradingView symbols. It's an internal data query, not an HTTP request.

This applies to every version of Pine Script, including v6. No paid plan changes it. No hidden function gives you that. If you're searching for a way to make Pine Script talk directly to an external server, you can stop. The answer is no.

The one workaround: webhook alerts

Pine Script can't make HTTP requests. But TradingView can.

TradingView's alert system includes webhooks: when an alert fires, TradingView's own servers send an HTTP POST to a URL you specify. Your Pine Script controls what triggers the alert and what data the payload carries (via the alert_message parameter). But your script never touches the network. TradingView handles the HTTP request on your behalf.

This is the only way to get data out of TradingView programmatically. There's no second option.

A few things worth knowing about webhooks. They require an Essential plan or higher (the free plan doesn't support them). The payload is a string you define in alert_message, usually formatted as JSON. And the webhook fires when TradingView's alert condition is met, which for strategies means the moment strategy.entry() or strategy.close() is called. Not when the fill happens. That distinction matters, and we'll come back to it.

If you've been considering whether to write your logic in Pine Script or Python, the webhook limitation is actually a point in Pine Script's favor. Python gives you HTTP access, sure, but it doesn't give you TradingView's charting, backtesting, or alert infrastructure. Most traders who evaluate both end up keeping their strategy in Pine Script and using webhooks for the execution layer. The tradeoffs of converting Pine Script to Python, including when Python actually makes sense, are a separate conversation.

What traders try instead (and why it fails)

Every few weeks someone on a TradingView forum posts a new theory about how to get around the HTTP restriction. None of them work.

request.security() as a network call. It isn't one. This function queries other symbols and timeframes within TradingView. It cannot reach external URLs, APIs, or databases. The name is misleading, but the behavior is clear.

External Pine Script libraries. Pine Script's import statement loads libraries published on TradingView. These libraries run in the same sandbox with the same restrictions. Importing a library doesn't give you capabilities that Pine Script itself doesn't have.

Upgrading to a higher TradingView plan. Premium and Premium+ give you more alerts, more indicators, and faster data. They don't give you HTTP access from Pine Script. The paid plan requirement applies specifically to webhooks for alerts (Essential+), not to outbound calls from scripts.

Browser extensions and local scripts. Some traders use a browser extension to scrape TradingView's UI, intercept the alert, and forward it to their broker's API. This technically works, but it requires Chrome to be running, breaks when TradingView updates their DOM, and adds a fragile human-operated machine to what should be a server-side pipeline. It's a workaround, not a fix. And for traders who've experienced TradingView alerts not working after a browser crash at 2 a.m., the reliability gap is real.

The honest answer is that the webhook path is it. If your strategy lives in Pine Script, which is where most automated trading starts, webhooks are the only supported way to get signals out.

What breaks after the webhook fires

Getting data out of TradingView is step one. Step two is turning that data into a real trade with your broker. And this is where most setups fail, for reasons that have nothing to do with Pine Script's HTTP limitation.

The webhook fires when your strategy calls strategy.entry(). At that instant, TradingView sends the POST. But the market may not have filled your order yet. The fill might come at a different price, or not at all. Your webhook receiver doesn't know this. It got the signal and already placed a trade on your broker. Now you have a position that doesn't match anything on your TradingView chart.

That's a ghost position. On XAUUSD at 1 lot, a ghost trade moving 50 points against you is a $5,000 loss on a position that shouldn't exist.

There are two other failure modes. On reversals, your strategy fires two webhooks within milliseconds: close the long, open the short. HTTP requests don't arrive in a predictable order. If "open short" reaches your broker before "close long," the EA opens the short. Both positions sit on the account briefly. 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.

And stop-loss levels drift when your actual fill price differs from the price your strategy assumed, because most bridges calculate SL as a distance from entry rather than using the absolute price your strategy logic specified.

These problems exist in every webhook-based automation setup. They're not specific to any one bridge or broker. They're structural, baked into how alert_message and HTTP delivery work. Understanding Pine Script limitations beyond just the HTTP restriction helps you see why the webhook path, while it works, needs careful engineering on the receiving end.

Why prop firm traders pay for these problems first

If you're trading a personal $2,000 account and a ghost position costs you $200, that hurts. But you recover.

On a prop firm evaluation, the math is different. A $50,000 FTMO account has a 5% daily drawdown limit: $2,500. One phantom trade on US30 moving 50 points against you at 1 lot burns $500 of that limit. That's 20% of your daily allowance consumed by a trade that shouldn't exist. And you paid $300 for the evaluation itself.

Signal reordering on a reversal can leave you in the wrong direction for minutes before you notice. On a prop firm account with strict drawdown rules, minutes in the wrong direction can end the evaluation. SL drift of 2 points sounds trivial until it's the difference between respecting a support level and getting stopped out early during a volatile London session.

The people who hit these problems first are almost always on prop firm accounts. Not because they're doing anything wrong, but because their margin for error is the smallest. A working strategy plus a broken bridge equals a failed evaluation, and the cost of that is the evaluation fee plus the time spent preparing. If you're setting up TradingView automated trading for a funded account, the execution layer matters as much as the strategy itself.

How FillEdge handles signals

FillEdge is a webhook bridge. Your Pine Script strategy fires an alert, TradingView sends a webhook to FillEdge, and FillEdge places the trade on your broker. The basic flow is the same as any other bridge. The difference is in what happens between receiving the webhook and placing the order.

FillEdge doesn't send a trade to your broker the instant the webhook arrives. It waits for fill confirmation. If the fill doesn't happen on TradingView's side, nothing gets sent to your broker. Ghost positions don't reach your account because they're caught before they leave the pipeline.

On reversals, FillEdge processes signals in the correct sequence regardless of when the HTTP requests arrive. Close always happens before the new open. You won't end up holding the position your strategy was trying to exit.

Stop-loss and take-profit levels land where your strategy logic intended. You choose per strategy: exact-price mode keeps your SL at 43,250 whether you filled at 43,300 or 43,302, while distance mode preserves the offset from actual entry for volatility-scaled strategies. The bridge respects your logic either way.

And if you're running multiple strategies, each one operates in isolation. Your EURUSD mean-reversion signals will never close a position belonging to your US30 trend strategy, even on the same broker account.

Every signal carries a status badge. ✓MATCHED means TradingView and your broker agree. 👻CAUGHT means a ghost was blocked. 🔀REORDERED means a reversal was sequenced correctly. You verify that your chart and your broker tell the same story without comparing timestamps by hand.

FillEdge also monitors the pipeline on its own. Synthetic test signals travel the full path on a regular cadence, without opening a trade. If the EA disconnects or the webhook stops arriving, you hear within minutes via email or Telegram.

The setup takes about 15 minutes. You add FillEdge's template to your Pine Script (it wraps around your existing logic, no rewriting), install the Expert Advisor on your broker's terminal, and point a TradingView webhook alert at your FillEdge URL. There's a dashboard that shows every signal matched against every trade, so you can verify that what happened on your chart is what happened on your broker. If something stops working, whether it's the alert, the webhook, or the EA connection, you get notified before the damage compounds.

Pine Script can't make HTTP requests directly, and honestly, it doesn't need to. The webhook path works. What matters is what sits on the other end of that webhook, catching the problems that TradingView's alert system wasn't designed to handle.

FAQ

Can Pine Script send data to a database or Google Sheet?

Not directly. Pine Script can't make outbound HTTP requests to any external service, including Google Sheets, Firebase, or your own database. The workaround is the same one used for trade execution: set up a webhook alert that POSTs to an intermediary (like Zapier, Make, or a simple cloud function), which then writes to your database or spreadsheet. Your Pine Script defines what data goes into the alert_message payload, and the receiving service handles the rest.

Does Pine Script support WebSocket connections?

No. Pine Script has no access to WebSockets, TCP sockets, or any other networking protocol. It runs in TradingView's server-side sandbox with zero outbound network capability. The only data that leaves TradingView programmatically is through webhook alerts, which are one-directional HTTP POSTs. There's no way to establish a persistent two-way connection from a Pine Script.

Can I use Pine Script with Binance or other broker APIs?

Pine Script can't call any external API directly, whether it's Binance, OANDA, or any other broker. The language doesn't have HTTP functions, so there's no way to authenticate with an API, send an order, or read account data from within a script. To connect Pine Script signals to a broker, you route them through TradingView's webhook system to a bridge or automation service that talks to your broker's API on your behalf.