TradingView Webhook to Telegram
One alert takes one URL — where do you fan out?

You set up a TradingView alert, and the webhook (the channel that HTTP POSTs your signal to a URL you specify) is pointing at your exchange bot. Then you realize you can only fill in one URL — you also wanted a Telegram message saying "filled, price was X," but there's no second field to put it in.

Nobody tells you this up front: a TradingView alert takes exactly one webhook URL. Getting "TradingView webhook into Telegram and the exchange at the same time" means adding a layer in the middle — whether that's a proxy you wrote yourself, an alert pointed straight at a Telegram bot (no order), or a middleware service that does both at once. Whether that middle layer actually places orders is what decides who has to hold the API key (the credentials that authorize placing orders and querying accounts). This post doesn't pick a winner or judge your strategy. It gives you three things: the trade-offs across three fan-out positions, the ordering and dedup traps you will hit, and how to run a Telegram-only, no-order observation period.

Why "Fire Telegram and the Exchange in One Shot" Isn't TradingView's Job

The TradingView alert panel has: condition, name, expiration, notification channels (App, Email, Webhook). The webhook slot is a single text input, not a list — you get one URL and one payload. This is by design, not a bug. TradingView pushes "where does it go" onto an endpoint you own, and what happens after that endpoint isn't their problem.

So "fire the order and notify me at the same time" has to be wired up on the webhook URL side. The fields you actually want in the message — "entered, filled at what price, did anything fail" — don't exist until the exchange responds; at the moment the alert fires they have no value yet. Fan-out isn't a "TradingView sends two copies" problem — it's "once your webhook receives the signal, how do you get both the order result and the Telegram message out of the same flow." Frame it wrong and ordering, dedup, and rate limits will all be set wrong downstream.

Three Places to Put the Fan-Out, Each Optimizing Something Different

Same "fire the order and notify me" goal, but where you put the middle layer changes a lot. This table is here for comparison — don't memorize it. Pick one, then come back to that column's trade-offs.

The second option — "TradingView pointed straight at a Telegram bot" — is the most underrated. You point the alert's webhook URL directly at https://api.telegram.org/bot<TOKEN>/sendMessage, put the message content into the chat_id and text JSON fields inside the alert message, and you get the notification without ever placing an order. Good for the phase where you're still watching whether the strategy is any good and not ready to place real orders. Downside: TradingView resends on 5xx and you'll get duplicates (Telegram's sendMessage has no idempotency key).

Ordering Trap: Sending Telegram Before the Order Is a False Success Report

This is the easiest section to get wrong. Say your middle layer is written as "send Telegram first to tell the user we got it, then hit the exchange to place the order." The message reads: "Signal received, BTCUSDT buy 0.01." Then the order hits insufficient balance, min notional, or an API key (the credentials that authorize placing orders and querying accounts) without futures permission — any one of these means the order simply didn't happen, but the user already believes "we're in."

The correct order is to bind the Telegram notification to the last step of the order flow — run pre-checks, hit the exchange API, get either a fill or a clear error message, and only then push to Telegram. This isn't taste, it's mechanically correct: every field in the Telegram message needs the order to have happened first (fill price, actual quantity, remaining balance, failure reason). "For example," TVSBot's execution side calls _send_notification only after process_signal completes (backend/app/services/orders.py) — fill price, per-key ✓/✗ result, and the specific error on failure all come from the exchange's response.

Dedup Trap: TradingView Resends on 5xx, Telegram Gets Two Messages

TradingView's official webhook delivery spec is 3-second timeout on the receiving end with no retry; 4xx also no retry; only 5xx waits 5 seconds and resends up to 3 times (see our other post: TradingView Webhook Delay: Official Specs, Common Causes, and What You Can Fix). This means: if your middle layer hits a transient 5xx from the exchange during order placement and you pass that 5xx straight back to TradingView, the same alert gets sent 2 to 4 times. Telegram receives 2 to 4 "filled" messages, but only 1 position actually opened — the others may be no-ops thanks to the exchange's own idempotency or dedup.

The fix is doing dedup in the middle layer and not passing resends downstream. The key should include at least strategy, symbol, action, and qty, ideally with a time window (60 seconds of same-hash → skip). TVSBot's execution side does this at step 4 in backend/app/routers/webhook.py: payload hash on user_id|strategy|symbol|action|qty, skip if seen in the last 60 seconds.

Rate Limit Trap: Telegram Bot API Has Per-Second Limits

Telegram Bot API has per-second rate limits on sendMessage — roughly 1 message/second per chat, with a separate aggregate limit across chats; exceeding them returns 429 with a retry_after (check the Telegram Bot API FAQ for the current numbers — they reserve the right to adjust anytime). Single-user personal setups rarely hit this, but if you're running "one strategy fanned out to many accounts" or "notifying a community of 100 subscribers," a burst of high-frequency alerts will blow through it in one go.

This one breaks quietly: Telegram just returns 429, doesn't backfill, and you won't know messages were dropped unless you look. Options: add a message queue in the middle layer, backing off past the per-second limit and logging how many were dropped. Or, more pragmatically: switch Telegram notifications from "one per order" to "one hourly digest" — plenty for a single retail user.

Telegram-Only, No-Order Observation Period: This Is What Dry-Run Is For

An often-overlooked use case: treat Telegram as a "strategy test board." You want to see how many signals a new strategy fires in real market conditions, at what times, and whether the direction is right — but not with real money yet. In this case you don't want "notify + order at the same time" — you want "notify only, no order."

Two ways to do it. Option one: point the TradingView alert directly at Telegram Bot API's sendMessage, no order logic in between. Downsides as noted above — resends and rate limits are on you, and the message carries no validation of "could the exchange actually accept this signal" (no min notional, leverage settings, or available balance checks). Option two: run through a middleware with dry-run turned on. "For example," every TVSBot strategy has a dry_run switch; turn it on and the signal runs through the full pre-check + fake-order flow, writes "this would open 0.03 BTC, simulated fill at 65,432" into the Telegram message, and never touches the exchange — the subscription gate also lets non-paying users through (backend/app/services/orders.py's force_dry_run and the strategy-level dry_run both flow into the same logic).

You Don't Have to Write the Proxy Yourself — Just Understand the Four Things It Does

Whether to write this middle layer yourself is a trade-off. See clearly what it does, then decide whether to take it on. Any middle layer doing "TradingView → Telegram + exchange" fan-out handles the four things below. Use this as a checklist — whether you write it or pick a middleware, it's about whether these four are handled.

• Verify identity. The webhook URL is reachable by the whole internet, so you must include a long token in the URL or payload for auth. Use hmac.compare_digest-style constant-time comparison — a plain == leaks byte-by-byte to a timing attack.
• Rate limit. One cap per token and one per IP, so an attacker who knows your URL still can't take the middle layer down.
• Dedup. Hash strategy + symbol + action + qty, skip any signal already seen within a 60-second window. This blocks TradingView's 5xx resends and manual replays.
• Order first, notify second. The Telegram message must be bound to the last step of the order flow — that's the only way the fill price and failure reason in the message are real, not "what I assumed."

An Honest Section: Telegram Can't Be Your Kill Switch

This one is something we've regretted doing ourselves: treating Telegram as the only notification channel. Telegram doesn't guarantee immediacy, doesn't guarantee delivery, and you don't get a "this message got dropped" notification — Telegram has no such mechanism. No automated trading architecture can guarantee 100% delivery — including ours. If you plan to rely on Telegram notifications to "jump in and fix things" when an order fails, that dependency is fragile: no phone signal, batched-mute notifications, or a message dropped by rate limits in the middle layer — you can miss an entire event.

If you genuinely need a notification that will wake you at 3am, use SMS or phone polling (PagerDuty, Opsgenie, that kind of thing), not IM. Telegram is good for "after-the-fact reconciliation" and "routine notifications," not for "this exception must be seen." The flip side: a kill switch — a button that has to stop trading immediately — cannot live only inside a Telegram bot. It needs a web dashboard version too, reachable from your phone browser or a friend's computer.

FAQ