MetaTrader 5 can pop a notification inside the terminal, and it can push to the MetaQuotes mobile app. Neither reaches the place your attention actually lives: the Telegram group with your trading partners, the Discord server your community runs, the Slack channel your team watches. Bridging that gap is one of the most-asked MT5 questions, so here are the three real routes — and the platform-specific formatting rules that decide whether your message renders or gets rejected.
Route 1: an MQL5 EA with WebRequest
The DIY route: write an Expert Advisor that detects the event you care about
and calls WebRequest to a chat platform's API. It works, with the usual DIY
bills attached: the EA runs per terminal (so per account), the terminal must
stay open and logged in, the destination URL must be whitelisted in the
terminal's options, and you now own the retry logic, the escaping, and the
maintenance every time anything changes.
If the alert matters — a drawdown limit on a funded account, say — "runs while my desktop is up" is a serious caveat.
Route 2: a webhook relay you host
The architectural route: something emits a generic webhook on trading events, and a small relay you host reformats it per platform and forwards it. Clean separation, any language, and one relay serves every destination.
You've traded the EA's problems for hosting ones: the relay is a service with uptime, and you're now on the hook for each platform's formatting rules — which are stricter and stranger than they look. More on those below, because they bite regardless of route.
Route 3: platform-native delivery
The buy-not-build route: a platform that already runs your MT5 account server-side sends the alert itself, pre-formatted per destination. On MetaKit, an equity monitor takes a Slack, Discord, or Telegram destination (or a raw webhook) directly — the account runs in the cloud, so delivery doesn't depend on any machine of yours, and each platform gets its native format: Block Kit for Slack, a rich embed for Discord, formatted HTML for Telegram. There's a "send test" button precisely because the right time to discover a broken webhook URL is now, not during a drawdown at 3am.
The formatting rules that reject your messages
Whichever route you take, these are the rules we learned building (and payload-testing) the native delivery. Hand-rollers hit every one of them:
Discord wants an embeds array — a single embed object outside an
array is rejected. Embed colors are integers (15548997), not hex strings
("#ED4245"). Limits that 400 you: max 10 embeds per message, 25 fields per
embed, 256-character titles — and every field needs a non-empty name and
value.
Slack incoming webhooks accept Block Kit blocks, but you must still send
a top-level text — it's the fallback used by mobile push notifications,
and without it your pings arrive blank. Header blocks take plain_text only
(mrkdwn in a header is rejected), and a section holds at most 10 fields.
Telegram is a bot-API call (sendMessage with a bot token from
@BotFather and a chat_id), not a webhook URL. With parse_mode: HTML you
must escape <, >, and & in any dynamic text — one account named
IC Markets <Live> will otherwise kill the whole message. (Fittingly, that
same unescaped bracket broke this very page's build the first time: in MDX,
like in Telegram, a bare <Live> is parsed as markup.) Messages cap at
4096 characters, and the error responses carry a useful description field
that generic HTTP error handling throws away.
One rule spans all three: an alert channel needs a test path. Every platform fails silently from the sender's perspective — the POST returns an error, your fire-and-forget code ignores it, and you find out weeks later that alerts stopped. Log delivery results, surface failures, and send a test message on every configuration change.
Which route, honestly
| EA + WebRequest | Your own relay | Platform-native | |
|---|---|---|---|
| Runs when your PC is off | ❌ | ✅ (if hosted) | ✅ |
| Per-platform formatting | You | You | Done |
| Infrastructure you maintain | Terminal + EA | Relay service | None |
| Cost | Time | Time + hosting | Subscription |
| Fits | One account, tinkering | Custom routing needs | Alerts that must arrive |
The pattern is the same one from our MetaTrader 5 API guide: the further the plumbing sits from your desktop, the more reliable the outcome and the less of it you maintain. For alerts specifically — whose entire job is to work when you're not looking — that tradeoff leans harder than usual toward whichever option doesn't depend on your machine being on.