How a Telegram to MetaTrader bridge actually works

2 October 2026 · Soft Trade Enterprises · All guides

What the software does and does not do

Before the architecture, the boundary. A bridge is a message transport. It reads text from a channel you own or are authorised to read, interprets it according to a format you define, and places the corresponding order on your own terminal using your own risk settings.

It does not decide anything. The channel content is yours, the decision to act on it is yours, and the risk rules are yours. We supply software; we do not supply, endorse or evaluate the content of any channel.

The four parts

Part	Job	Typical failure
Reader	Receive new messages from Telegram	Session expiry, rate limits, reconnection
Parser	Turn free text into a structured instruction	Format drift, ambiguous text, edits
Mapper	Resolve symbol names and sizes to your broker	Suffixes, missing symbols, lot steps
Executor	Place and manage the order on MT5	Retcodes, requotes, partial fills

Most of the real work is in the parser. The other three are well-understood engineering; the parser has to cope with how a human actually writes.

Reading the channel

Two approaches. The Telegram Bot API is simple and officially supported, but a bot must be added to the channel, which you cannot do to a channel you do not administer. The MTProto client API reads as your own user account and can therefore read any channel you have joined.

Which one applies depends entirely on whether the channel is yours. We ask that question first, because it decides the whole build.

Parsing: the part that earns its fee

Real messages are not structured. The same instruction might arrive as any of these:

XAUUSD BUY @ 2650
Gold buy now 2650, sl 2640, tp 2670
🟢 BUY XAU/USD
Entry: 2650
SL 2640
TP1 2660 TP2 2670

A parser built on guesswork will handle two of those and quietly mis-handle the third, which is worse than failing. This is why we ask for ten to twenty real messages before quoting — the parser is written against the actual format, not an imagined one.

Three rules we build in every time:

• Refuse rather than guess. If a message does not parse with confidence, it is logged and skipped. A missed message is recoverable; a misread one is not.
• Deduplicate. Telegram can deliver the same message twice, and edits arrive as fresh events. Track message IDs and ignore repeats.
• Handle edits and replies. "SL to BE" as a reply to an earlier message only makes sense if the bridge remembers which order that message created.

Symbol mapping is not optional

A message says GOLD. Your broker calls it XAUUSD.m. Without an explicit mapping table the order simply fails.

SYMBOL_MAP = {
    "GOLD":    "XAUUSD.m",
    "XAU/USD": "XAUUSD.m",
    "XAUUSD":  "XAUUSD.m",
}

def resolve(raw):
    sym = SYMBOL_MAP.get(raw.upper().replace(" ", ""))
    if sym is None:
        log.warning("Unmapped symbol %s - message skipped", raw)
        return None
    return sym

Your risk rules, not the message's

This is the part clients most often ask to change after a week of use, so it is worth getting right at the start. The message may suggest a lot size. The bridge should apply your sizing rule — fixed lot, percentage risk based on the stop distance, or a cap — and your limits on maximum open positions and daily exposure, regardless of what the message says.

Failure handling is most of the code

• Reconnect with backoff when Telegram drops
• Reconnect to the MT5 terminal if it restarts
• Retry transient trade retcodes, never retry a rejection that will fail identically
• Record every message received, every decision made and every result, with timestamps

That last one is the feature clients end up valuing most. When something looks wrong, the log shows exactly what arrived, how it was read and what the server replied.

It has to keep running

A bridge only works while it is running. Laptops sleep, home internet drops, Windows reboots for updates at 3am. This is why most bridges end up on a VPS, and why the deployment is part of the job rather than an afterthought.