How to Connect TradingView to MT5 Without Code (2026)

parrifever6999-sudo — Wed, 15 Jul 2026 21:07:47 +0000

TradingView is where most of us build and backtest strategies. MetaTrader 5 is where most brokers actually execute them. Connecting the two used to mean writing a custom bridge or paying for a pricey plugin — but in 2026 you can do it in about five minutes, with no code. Here's the no-code way to connect TradingView to MT5 that I use every day for SignalForge.

You need three things: a TradingView account (Essential plan or above — free plans can't send webhooks), an MT5 broker account, and a bridge that gives you a webhook URL plus a small Expert Advisor (EA) to drop into MT5.

Step 1 — Create the alert in TradingView

Open your chart, load your Pine Script strategy or indicator, and hit Create Alert. Pick the condition that should fire — a strategy entry, a crossover, an indicator signal.

Step 2 — Add the webhook URL and the message

In the alert's Notifications tab, check Webhook URL and paste the URL your bridge gives you. Then set the alert message to a format the bridge understands.

Most bridges (SignalForge included) accept a few message formats, so your existing Pine Script keeps working without changes:

buy XAUUSD lot=0.01 sl=1500 tp=4000

or as JSON:

{"action": "buy", "symbol": "XAUUSD", "lot": 0.01, "sl": 1500, "tp": 4000}

Here's the alert message field in TradingView, using its built-in placeholders:

Step 3 — Attach the EA on MetaTrader 5

In MT5, drag your bridge's Expert Advisor onto a chart and paste your token in the EA inputs. The EA polls for pending signals and executes them on your broker account — no DLLs, no manual order entry.

Step 4 — Confirm it's live

Open your bridge's dashboard. Within seconds of the first TradingView alert, you should see the MT5 account connected and signals flowing.

Gotchas that bite

Symbol case matters. US30.cash on FTMO is not US30.CASH. Send the exact symbol string your broker recognizes or the trade fails with "symbol not found." This is the #1 setup error I see.
Free TradingView can't send webhooks. You need Essential ($12.95/mo) or higher for the webhook option to appear.
MT5 must be running. On most plans the EA lives inside your MT5 terminal, so MT5 (or a cheap VPS) needs to be up during market hours.
MT5, not MT4. Most modern bridges are MT5-first. If you're locked into MT4, your options narrow.

Try it

SignalForge is the $4.99/mo bridge I built for exactly this — it reads the PineConnector message format natively, so migrating takes about five minutes and a 14-day free trial (no card). See the full how to connect TradingView to MT5 walkthrough, or compare the best TradingView to MT5 bridges if you're shopping around.

If you hit a snag during setup, drop a comment — I read all of them.

Benjamin builds trading infrastructure from Alicante, Spain. He's the solo founder of SignalForge AI, a TradingView-to-MT5 bridge.

How I Cut My TradingView-to-MT5 Bridge Latency from 12 Seconds to 187ms

parrifever6999-sudo — Thu, 23 Apr 2026 18:07:00 +0000

TradingView is where most retail traders build strategies. MetaTrader 5 is where most brokers execute trades. The gap between them is a webhook — and filling that gap reliably at low latency turned out to be a surprisingly deep engineering problem.

I'm the solo founder of SignalForge AI, a TradingView to MT5 bridge SaaS. This post covers the architecture decisions, the bugs that cost real money, and the latency optimization that took execution from 12 seconds to 187ms (p50).

The architecture in 30 seconds

TradingView Alert (webhook)
        |
        v
  Flask on Railway (US East)
  - Authenticate token
  - Parse signal (3 formats)
  - Route to broker account(s)
  - Store in PostgreSQL
        |
        v
  MT5 Expert Advisor (on client PC)
  - Polls /ea/poll/<token> every 500ms
  - Picks up pending signal
  - Executes on broker
  - Reports back to /ea/ack

No WebSockets. No message queue. Just HTTP polling. I'll explain why.

Why polling beats WebSockets here

The MT5 Expert Advisor (EA) runs inside MetaTrader, which is a Win32 application from 2010. MQL5 (the EA programming language) supports WebRequest() for HTTP but has no native WebSocket client. You can hack one with DLLs, but:

DLLs require the user to enable "Allow DLL imports" (security risk, scares users)
DLL WebSocket libraries in MQL5 are fragile and poorly maintained
If the WebSocket drops, reconnection logic in MQL5 is painful

HTTP polling at 500ms intervals gives ~250ms average latency (half the polling interval) which is perfectly acceptable for trade execution. The total end-to-end from TradingView alert to MT5 order is 375-875ms, well under the 1-second threshold traders care about.

The simplicity also means the EA is a few hundred lines of MQL5 with zero external dependencies.

The multi-format parser

TradingView alerts can send any text as a webhook payload. Different traders use different formats, and I wanted to support all of them without forcing a specific syntax. The parser accepts three formats:

Key-value (our native format):

   buy XAUUSD lot=0.01 sl=1500 tp=4000

JSON:

   {"action": "buy", "symbol": "XAUUSD", "lot": 0.01, "sl": 1500, "tp": 4000}

PineConnector-compatible compact:

   short US30.cash lot=0.5 sl=1000 tp=1300

The parser tries JSON first (cheapest check), then falls back to key-value splitting. Action aliases are normalized: long becomes buy, short becomes sell, closelong/closeshort/closeall become close.

FIELD_ALIASES = {
    'ticker': 'symbol',
    'volume': 'lot',
    'signal': 'action',
    'stop_loss': 'sl',
    'take_profit': 'tp',
    'takeprofit': 'tp',
    'stoploss': 'sl',
}

ACTION_ALIASES = {
    'long': 'buy',
    'short': 'sell',
    'closelong': 'close',
    'closeshort': 'close',
    'closeall': 'close',
}

One deliberate decision: quantity is not aliased to lot. In futures, quantity means contracts. In forex, lot means lot size. Conflating them silently would cause position sizing errors that cost real money. If someone sends quantity=5, the parser rejects it with a clear error rather than opening 5 lots of gold.

The bug that broke a prop firm challenge

An early user was running PineConnector-style alerts on FTMO with US30.cash as the symbol. His trades were failing with "symbol not found."

The bug: I had .upper() on the symbol field for normalization. Turns out FTMO's MT5 instance uses US30.cash (mixed case), not US30.CASH. Other brokers use XAUUSD.m, EURUSD.raw, etc. Case matters.

The fix was one line: remove .upper() and preserve the symbol exactly as the trader sends it. But it was a reminder that in trading infrastructure, every normalization is a potential break. The symbol the trader types must be the exact symbol their broker recognizes.

From 12 seconds to 187ms: the latency fix

After launch, some signals were taking 12+ seconds to execute. For a scalping strategy, that's catastrophic — the entry price has moved significantly.

The culprit: expire_old_signals(). This function cleans up signals older than 60 seconds so they don't execute stale. I was calling it on every single request — every poll, every webhook, every ping.

On a PostgreSQL database hosted on Railway, each call triggered DELETE FROM signals WHERE created_at < NOW() - interval '60 seconds'. With WAL checkpoints and Railway's shared disk I/O, this added 2-8 seconds of latency randomly.

The fix: call expire_old_signals() at most once every 60 seconds using a simple timestamp check:

_last_expire = 0

def maybe_expire_signals():
    global _last_expire
    now = time.time()
    if now - _last_expire > 60:
        _last_expire = now
        expire_old_signals()

Median latency dropped from 12 seconds to 187ms (p50). The commit hash is burned into my memory.

Multi-broker routing

Most bridge tools support one broker account. Traders running multiple accounts (e.g., a personal account plus a prop firm challenge) need one alert to execute on all of them.

The routing logic:

def _get_target_brokers(user, signal_data):
    active = BrokerAccount.query.filter_by(
        user_id=user.id, status='active'
    ).all()

    # If signal specifies an account, route to that one only
    target_account = signal_data.get('account')
    if target_account:
        return [b for b in active if b.mt5_login == target_account]

    # Otherwise broadcast to all active accounts
    return active

Plan limits are enforced at registration time (Starter: 1 account, Trader: 3, Pro: 10) so the broadcast is always bounded.

Auto-registration of MT5 accounts

Users kept getting stuck at the "connect your MT5" step. They'd install the EA, paste their token, but the backend had no record of their MT5 login number.

The solution: the EA pings /ea/ping/<token> every 30 seconds with the MT5 login in the headers. If the backend sees an unknown login, it auto-registers it:

@app.route('/ea/ping/<token>')
def ea_ping(token):
    user = User.query.filter_by(webhook_token=token).first()
    if not user:
        return jsonify({'status': 'invalid_token'}), 401

    mt5_login = request.headers.get('X-MT5-Login')
    if mt5_login:
        existing = BrokerAccount.query.filter_by(
            user_id=user.id, mt5_login=mt5_login
        ).first()
        if not existing:
            register_mt5_account(user, mt5_login)

    return jsonify({'status': 'ok'})

This eliminated the most common support ticket overnight.

Railway deployment specifics

The entire backend runs on Railway (Flask + PostgreSQL). Some things I learned:

Region matters. I started on Singapore (default). Latency to TradingView's webhook servers (US-based) was 200ms+ just for the network hop. Moving to US East cut that to ~20ms.
Auto-deploy is the workflow. Push to main on GitHub, Railway builds and deploys in ~45 seconds. No CI/CD config, no Docker (Railway detects the Python buildpack automatically). For a solo founder, this is the ideal balance of speed and reliability.
PostgreSQL cold starts. Railway's managed Postgres occasionally takes 1-2 seconds on the first query after idle periods. For a trading app where every millisecond matters during market hours, this is noticeable. The fix: the EA's 30-second ping acts as a keep-alive that prevents the database from going cold during trading sessions.
Gunicorn timeout. Set to 120 seconds in anticipation of the AI filter (coming Q3 2026 on the Pro plan), which will call an external LLM API that can take 3-8 seconds — the default 30-second timeout would have killed those requests.

What I'd do differently

Use a proper job queue. Right now, signal processing is synchronous in the request handler. If I were starting over, I'd use Redis + Celery (or even just a simple threading.Thread) to return 200 immediately and process the signal async. The current approach works at my scale but won't scale to millions of signals.
Separate read/write databases. The polling endpoint is 95% of all traffic and only reads. The webhook endpoint writes. At scale, a read replica would eliminate all contention.
WebSocket with fallback. If MQL5 ever gets native WebSocket support (or if I build a Windows service as a sidecar), the polling overhead disappears entirely. Average latency would drop from 250ms to <50ms.

The numbers so far

Median latency: 187ms p50 server-side (610ms p99), 375-875ms end-to-end
Codebase: a few thousand lines of Python (Flask) + a few hundred lines of MQL5 (EA)
Deploy time: ~45 seconds from git push to live

Try it

If you want to automate TradingView strategies on MetaTrader 5, SignalForge AI starts at $4.99/month with a 14-day free trial. The Trader plan ($14.99/mo) adds prop firm drawdown protection and a news filter — see the full best TradingView to MT5 bridge comparison for how it stacks up against PineConnector and TradingConnector.

If you're building something similar and have questions about the architecture, drop a comment or find me on YouTube.

Benjamin builds trading infrastructure from Alicante, Spain. He is the solo founder of SignalForge AI.

DEV Community: parrifever6999-sudo

How to Connect TradingView to MT5 Without Code (2026)

Step 1 — Create the alert in TradingView

Step 2 — Add the webhook URL and the message

Step 3 — Attach the EA on MetaTrader 5

Step 4 — Confirm it's live

Gotchas that bite

Try it

How I Cut My TradingView-to-MT5 Bridge Latency from 12 Seconds to 187ms

The architecture in 30 seconds

Why polling beats WebSockets here

The multi-format parser

The bug that broke a prop firm challenge

From 12 seconds to 187ms: the latency fix

Multi-broker routing

Auto-registration of MT5 accounts

Railway deployment specifics

What I'd do differently

The numbers so far

Try it