You've built a strategy in TradingView. The backtest looks strong, the alerts fire reliably — but MetaTrader 5 has no public way to receive a webhook. That disconnect is why most traders either execute manually (slow, emotional, error-prone) or pay for expensive copy-trading services they can't fully control.

This guide explains exactly how a TradingView webhook to MT5 bridge works: the architecture, the security model, the latency, and what breaks at scale. By the end you'll understand the pieces well enough to either build one yourself or evaluate whether a managed service like iNakaTrader fits your workflow.

What a TradingView webhook actually sends

When a TradingView alert fires, it makes an HTTP POST request to a URL you provide. The body is whatever text you put in the Message field of the alert. That's it — no fancy protocol, no authentication header you can configure, no retry mechanism.

A minimal webhook body looks like this:

{
  "action": "buy",
  "symbol": "EURUSD",
  "price": 1.0842,
  "magic": 12345,
  "key": "YOUR_LICENSE_KEY"
}

TradingView substitutes placeholders like {{ticker}} and {{close}} before sending. The receiving server gets a plain JSON or text payload over HTTPS — no callback, no streaming, no guaranteed delivery. If your server is down when the alert fires, the signal is lost.

This matters for one reason: TradingView assumes you have a server ready to listen 24/7. If you don't, or if that server can't forward the signal into MT5, the entire automation breaks.

Why MT5 is the hard part

MetaTrader 5 has no inbound webhook support. It's a desktop application that speaks its own protocol to the broker. You cannot point a TradingView alert at an MT5 terminal, at any IP address, or at any port MT5 exposes.

There are three real ways around this:

  1. MQL5 Expert Advisor polls your own server. The EA runs inside MT5, loops every few hundred milliseconds, and asks your server, "any new signals?" When it gets one, it places the trade using MT5's native order functions. This is the architecture iNakaTrader uses.
  2. Python script via the MetaTrader5 package. A local Python process connects to a running MT5 terminal on the same machine and fires orders through the official MetaTrader5 library. The script can also receive webhooks directly via Flask. Fewer moving parts, but MT5 must stay open on a Windows box.
  3. A commercial bridge service. Third-party services expose their own webhook URL, receive the alert, and route the order to your broker via FIX or a proprietary API. Convenient but a black box — you can't audit execution logic, and latency is out of your control.

Each approach has tradeoffs. Polling feels slow on paper but is surprisingly robust: if the EA or the server restarts, signals queue up and replay cleanly. Direct Python execution is faster but tightly coupled to one machine. Commercial bridges are easiest to start but costly at scale.

The signal-bridge architecture, end to end

Here's the flow iNakaTrader uses, which is representative of most production-quality TradingView to MT5 bridges:

TradingView Alert
      ↓ HTTPS POST
Nginx (TLS + rate limit)
      ↓
Flask signal server
      ↓ writes to
SQLite signal queue (per Magic Number)
      ↑ reads from
MQL5 Expert Advisor (polls every 500ms)
      ↓
MT5 broker execution

Five things make this reliable:

  1. Nginx in front. TLS termination, per-route rate limits (60 req/min on /webhook), and rejection of malformed requests before they hit the app.
  2. Stateless webhook handler. The Flask endpoint validates the signal, authenticates it (see below), and enqueues it. No trading logic runs in the webhook path.
  3. Per-strategy queues. Each Magic Number (MT5's identifier for an EA instance) has its own in-memory deque protected by a lock. That way two strategies running on the same account can't accidentally interfere with each other's state machine.
  4. Signal TTL. Queued signals expire after 5 minutes by default. If the EA is disconnected during a momentary network blip, the signal replays when it reconnects — but stale signals from an hour ago won't execute at outdated prices.
  5. EA-reported events. When a trade hits TP or SL inside MT5, the EA posts back to /ea_event so the server knows the strategy's current position state. That closes the loop: the server can reject a duplicate "buy" signal if a position is already open.

The entire round-trip — TradingView alert → server → EA poll → MT5 fill — is typically 500ms to 2 seconds. That's slower than co-located HFT but fast enough for any swing or intraday strategy running on 1-minute or higher timeframes.

The three authentication methods, and why they exist

The single biggest mistake in a DIY TradingView webhook to MT5 setup is leaving the webhook URL unauthenticated. If an attacker scrapes or guesses your URL, they can send fake signals and drain your account.

TradingView's alert system has one painful limitation: you cannot send custom HTTP headers. The entire alert config is URL + body. That forces any authentication scheme into one of three shapes:

  1. HMAC-SHA256 with timestamp. The alert body includes a timestamp field and a signature computed as HMAC(secret, body). The server verifies the signature and rejects requests where the timestamp is older than 60 seconds (replay protection). This is the gold standard but requires a TradingView Premium plan to template the signature into the alert.
  2. Shared secret in the URL path or query. The webhook URL is https://your-server/webhook?token=LONG_RANDOM_STRING. Simple and works with any TradingView plan, but the token ends up in access logs on every hop. Rotate it if you suspect a leak.
  3. Shared secret as an HTTP header. Works if you're using a proxy between TradingView and your server that can inject the header. In pure TradingView → server setups, you can't do this directly.

iNakaTrader supports all three. New deployments default to per-license random URL tokens (64 hex characters), and we rotate them via an admin endpoint if a key is ever exposed. See our webhook security guide for how rotation works without requiring users to update every TradingView alert.

Why plain IP allowlisting isn't enough

TradingView publishes the IP ranges its webhooks originate from, and some tutorials suggest locking your server to those CIDRs. Don't rely on that alone. IP ranges change without notice, and a misconfigured CDN or proxy in front of your server can mask the true origin. Use IP allowlisting as defense in depth, layered on top of HMAC or token authentication — never as the only gate.

Common failure modes at scale

Once you're past the "hello world" phase of webhook trading, a predictable set of problems shows up:

Most of these aren't webhook problems — they're trading-execution problems. But they show up in the webhook-to-MT5 pipeline because that's where the signal meets reality.

How iNakaTrader handles this

We built iNakaTrader to solve the above end to end. The signal server is a Flask application behind Nginx with TLS, per-license authentication, per-Magic-Number queues, and a 5-minute signal TTL. The MQL5 EA polls every 500ms, places trades using MT5's native order API, tracks position state, and reports events back to the server. A dashboard shows live strategies, recent signals, and lets you revoke or rotate credentials without touching TradingView alerts.

Pricing starts at $29/month for a single Magic Number and scales to unlimited strategies on the Elite tier. Everything runs on your broker, your MT5 account, your strategies — we're signal infrastructure, not a black-box "profit generator."

If you want to see the setup flow, the 10-minute setup guide walks through TradingView alert configuration, EA installation, and license activation.

FAQ

Do I need a VPS to run this? Yes, if you want 24/7 execution. The MT5 terminal must be running for the EA to poll and place trades. Most brokers offer a free VPS to funded accounts, or you can rent one from any cloud provider for $5–$15/month.

What latency should I expect? Typical end-to-end latency (TradingView alert fires → MT5 order placed) is 500 milliseconds to 2 seconds. Most of that is network RTT; polling adds up to one EA cycle on top. For strategies on 5-minute candles or higher, this is effectively zero slippage. For scalping on tick charts, you'll want a different architecture.

Can I use Pine Script strategies or do I need to rewrite as alerts? Pine Script strategy.entry() and strategy.close() calls can be routed directly into alerts using strategy.order.alert_message. iNakaTrader has a dedicated "Pine Script mode" that maps these directly to MT5 execution without requiring the two-step alertX+alertY confirmation used for manual alerts.

What if my broker doesn't support FIX or MT5 has weird symbol names? The EA runs inside your MT5 terminal and uses whatever symbols your broker exposes. If your broker calls gold XAUUSD.m instead of XAUUSD, the EA's symbol mapping handles the translation. All execution is native to MT5 — no FIX, no broker-specific integration.

Is webhook trading legal? Yes, in every jurisdiction we're aware of. Webhook trading is just automated execution of your own strategy — no different from running any EA on MT5, except the signal originates from TradingView instead of MT5's Strategy Tester. Check your broker's terms of service for any restrictions on automated trading (most allow it without issue).

How do I secure my webhook URL? Use a long random token (64+ hex characters), and rotate it immediately if you suspect a leak. Never publish the URL in a GitHub repo, a screenshot, or a support ticket. If your bridge provider supports HMAC authentication, use it — it's strictly stronger than URL tokens. iNakaTrader supports all three common methods.

Ready to connect TradingView to MT5 without writing a line of MQL? Start with iNakaTrader →