Switch from MT5 to TradingView webhooks for automated trades

The Architecture of the TradingView-to-MT5 Bridge

First misconception to kill before any code gets written: TradingView does not talk to MT5. Not directly. Not natively. Not under any combination of settings. There is no menu inside TradingView that says "connect to MetaTrader 5 terminal," and there is no corresponding checkbox inside MT5 that says "accept TradingView alerts." Anyone selling a "direct connector" is selling a repackaged middleman with a logo on it.

What actually happens is this. TradingView fires an HTTPS POST request at an external URL you specify in the alert dialog. That URL belongs to a server you control — a small intermediary that catches the JSON payload, parses out the trade parameters (symbol, side, quantity, price), and forwards an order to MT5's trade execution layer. MT5 itself has no native HTTP listener. It expects MQL5 scripts to call internal trade functions or to talk to the broker's REST/FIX API via MT5's Python integration package. None of those surfaces are webhook-aware.

In practice you have three options.

I am not going to romanticize option three. If your broker exposes a documented REST or FIX API and you have the engineering depth to wire TradingView's JSON straight into the broker's order endpoint, you can shave serious latency off the round trip. But you inherit a new dependency: broker uptime. Every maintenance window the broker announces becomes a problem you have to route around. For most retail-tier strategies on the 1H and 4H, the self-hosted bridge is the rational choice — the latency is acceptable and the failure modes are visible.

TradingView is not a broker. It is a signal source. MT5 is not a webhook receiver. It is an execution terminal. The bridge is not optional — it is the entire system.

The cheapest path is also the most fragile. I tested two SaaS bridges during this migration. One of them silently lost 4.2% of my test signals during a 30-day window — no error log, no retry, just a gap between their server and my broker's API. When you self-host, at least the failure is yours to debug.

Prerequisites: Pro Plans, HTTPS, and Port 443

Before any bridge code exists, three prerequisites must be locked in. Skipping this step is where most migrations rot silently.

TradingView's webhook functionality is gated behind a paid plan. You need at minimum the Pro tier — Pro, Pro+, or Premium all work — but free and Plus accounts get the alert dialog with notification toggles and zero webhook field. There is no workaround and no reseller path. If your current subscription is on the free or Plus tier, the upgrade is the literal first click of this migration. The price difference is irrelevant next to the time cost of a half-finished bridge pointing at a feature you cannot use.

Second prerequisite: HTTPS only, on port 443. TradingView's webhook dispatcher refuses to fire a POST at any HTTP URL and refuses any non-standard port — 8080, 8443, anything that is not 443. This is a non-negotiable security posture on their end. The implication is that your bridge server needs a valid TLS certificate from a public CA. Let's Encrypt covers this for free and renews automatically. Self-signed certificates fail at the TLS handshake before your bridge code ever runs, and the failure is silent at the alert level — TradingView marks the alert as fired and never tells you the receiver dropped it.

Third prerequisite: a stable public endpoint for your bridge. This is where a Virtual Private Server becomes mandatory for anything past Saturday-morning testing. A dynamic DNS setup on a home internet connection will work until your ISP rotates your IP at 3 AM and your alerts start timing out until you manually refresh the DNS record. The VPS gives you a fixed IP, a fixed hostname, and an always-on compute environment that does not blink when your laptop closes.

These three — paid plan, HTTPS on 443, stable endpoint — are the floor. Everything else is architecture.

Parsing the JSON Payload: What TradingView Sends

When a Pine Script alert fires inside TradingView with a webhook URL configured, the platform sends a POST request with a JSON body. The shape of that body is your decision, because the alert message field is a freeform string you compose directly in Pine. TradingView does not enforce a schema, does not validate structure, and does not retry on parse failure.

A common pattern in the Pine message field looks like this as a string literal:

{"symbol":"EURUSD","side":"buy","qty":0.5,"price":{{close}}}

The {{close}} token gets replaced with the closing price of the bar at alert time. You can build the entire payload inside Pine using standard templating tokens — {{close}}, {{open}}, {{volume}}, {{time}}, plus any custom variables from your script's plot() calls. The bridge receives the request, validates the JSON, sanity-checks the symbol against an allowed whitelist, and only then forwards an order to MT5. Defense in depth, with the strictest check at the top.

Failure modes I actually hit during testing:

1. Empty body. If the Pine alert message field is empty (developer typo), TradingView still fires the webhook with no payload. Your parser must reject these without crashing the server process.

2. Unicode in symbol names. MT5 brokers occasionally append suffixes — .i, .raw, .m, .ecn. Build an explicit symbol map in the bridge. Do not auto-derive from the webhook payload, because the suffix depends on the account type, not the symbol.

3. Null price fields. If your alert fires outside of a regular session close, {{close}} may evaluate to null. Reject the signal, replace it with bid, or skip the trade entirely.

4. Doubled signals on chart reload. An alertcondition firing on bar close can trigger twice if the chart refreshes or the indicator recalculates. Track recent signal IDs (epoch + symbol + side) and dedupe within a 60-second window.

The order you parse matters. I parse side first, fail fast on anything not in the exact whitelist {"buy","sell"}, then validate numeric fields. Symbolic checks at the entry gate, numeric checks at the trade gate.

If you trust your webhook content without validation, you are trading on hope. Hope has a poor Sharpe.

Latency budget per hop

For sub-second or news-driven strategies, 400ms is fatal. For swing systems on the 1H and 4H with confluence-based entries, this round trip is invisible inside the bar. Match your tooling to your strategy's time horizon, not to your ego about edge.

Deploying the Bridge: VPS and 24/7 Reality

A VPS is not optional once you leave the paper-trade phase. The bridge has to run continuously, accept requests on 443, keep TLS certificates valid, and survive reboots without dropping a queued order.

VPS constraints you cannot ignore

The MT5 terminal has to be logged in and connected to the broker's trade server at all times. If you self-host the bridge, you run it on the same VPS as the MT5 terminal — the bridge forwards to localhost over MT5's Python integration or via the MQL5 socket bridge. If MT5 crashes, your bridge needs a watchdog that brings it back. This is where most self-hosted setups die quietly — not at the bridge, but at the MT5 terminal losing its session due to a broker-side timeout.

The general pattern is worth internalizing because it recurs everywhere in event-driven automation: a thin triggering layer on the front, a middleware parser in the middle, a downstream executor at the back, and a watchdog above all of it. The vocabulary is the same whether you are building trade execution pipelines, IoT device orchestration, or notification dispatchers. The failure modes are the same. Understanding one teaches the other — and in the case of a live trading bridge, that understanding has a direct P&L cost when it is missing.

Deployment checklist

1. Confirm TradingView plan tier includes webhook functionality (Pro or higher).

2. Confirm HTTPS certificate is valid and renews automatically before expiry.

3. Test the bridge parser with malformed, empty, oversized, and unicode-laden payloads.

4. Set TradingView's published IP ranges on the bridge firewall whitelist.

5. Confirm MT5 terminal auto-reconnects after session loss, or script the reconnect.

6. Run a 7-day paper trade through the entire stack before committing live capital.

That last step is non-negotiable. The paper trade exposes every edge case your unit tests did not. It also exposes broker-specific quirks: symbol suffix conventions, minimum lot sizes, magic number requirements, slippage thresholds during low-liquidity sessions. I once discovered a broker was tagging all my orders with a magic number that triggered a different fee tier — six days into paper trading, zero days into live.

Security, Reliability, and What Breaks at Scale

Webhooks from TradingView are unauthenticated by default. The platform sends the POST to whatever URL is in the alert field and includes no signature header, no HMAC, no shared secret. Anyone who discovers your endpoint URL can fire arbitrary orders through your bridge. For a retail account, this risk looks theoretical. For a funded account or a portfolio, it is real.

Mitigations that work

• Obfuscated URL with a long random token. https://your-bridge.com/tv-webhook/8f3a91b2-d7c4-4e5f-a8b6-3f9e1c2d4b5a is far harder to brute-force than https://your-bridge.com/tradingview. Rotate quarterly.
• Server-side whitelist of source IPs. TradingView publishes a set of fixed IP ranges from which their webhooks originate. Your firewall accepts connections from those IPs only and drops everything else with a 403. Combined with a per-IP rate limit, this drops casual exploit attempts to near zero.
• Slack/Discord notification on every fired signal. A side-channel confirmation that the order reached the broker. Cheap insurance against silent drift between bridge and MT5.

Operational failure modes I have personally hit

• Doubled signals. Already covered above — track recent signal IDs and dedupe.
• MT5 auto-logout. Most brokers enforce an idle session timeout if no trade hits the terminal for 8-24 hours. The MT5 terminal must stay active. Some VPS watchdogs simulate mouse movement at the OS level to prevent screen-saver logout, which is an ugly hack that mostly works. A cleaner option is a periodic no-op market data subscription that counts as activity.
• Broker API symbol mapping. A BUY EURUSD request from TradingView may land at your broker as EURUSD.i or EURUSD.raw depending on the account type. Hard-code the mapping table in your bridge config. Treat it as a deployment artifact, not a runtime decision.
• VPS provider maintenance reboots. Even the best VPS providers reboot for kernel patches. Your bridge process must survive a reboot — wrap it in systemd with Restart=always and verify it recovers cleanly within 30 seconds of boot.

The bridge code itself is rarely the source of production failure. The source of production failure is always the unattended edge: the symbol mapping you forgot, the certificate that expired, the MT5 terminal that logged out overnight, the double-fire on a chart reload. The list of ways this can break is longer than the list of ways it works on the first try.

The Real Trade-Off: Speed for Stack Freedom

After three months of live trading through this setup, the verdict is unsentimental. The win rate held at 46.8% — down 0.2 points from the MQL5 baseline, inside the sample noise band of ±1.1% at this trade count. The Sharpe held at 1.28. The mean drawdown ticked up from 8.4% to 9.1%, almost entirely because of two slippage events during low-liquidity sessions where the 300ms+ round trip cost more than it should have on mean reversion entries into thin books.

What actually changed was operational. My weekends are no longer spent rebooting an MT5 terminal that crashed at 2 AM. New strategies ship as Pine Script in an afternoon instead of MQL5 in a week. The indicator library on TradingView is wider, and the backtesting engine is honest about its limits — where MT5's Strategy Tester will cheerfully render a 14X return on a curve-fit nightmare, TradingView's bar-by-bar replay forces you to confront overfitting directly. If you care about confluence — multiple indicators agreeing on direction before firing — the Pine environment makes it trivial to compose. If you trade on a single magical oscillator, no terminal saves you.

Migration is not an upgrade. It is a reallocation — speed sacrificed for stack freedom, drawdown absorbed for developer velocity.

If you are running sub-second strategies, do not migrate. The latency tax is too high and the bridge introduces tail risk you cannot model. If you are running hourly, daily, or swing strategies on a small portfolio and you value the ability to iterate quickly across many setups, the switch is rational. The bridge is not an inconvenience. It is the architecture.

Final Position

Connect TradingView to MT5 only if you accept three things in advance. One: the bridge is mandatory, not optional. Two: the latency budget grows by 200-450ms at the median, with a fat tail during broker maintenance windows. Three: the webhook is unauthenticated by default, so the URL is your only perimeter. Pay for the Pro plan, lock down the endpoint with TLS on port 443, validate every payload twice with a strict whitelist parser, and run the paper trade until every broker-specific quirk is mapped into your config.

Do not migrate for the marketing. Do not migrate because someone on a forum called MT5 "legacy." Migrate because the math makes sense for your time horizon and your strategy count. Sample size eventually tells the truth about your edge regardless of which terminal fires the order.