Telegram automation is a bot token from BotFather, a way for your code to receive updates, and something useful to do with them. The receiving part is the decision that matters: a bot either polls Telegram’s servers in a loop or registers a webhook and gets each message delivered to a URL the moment it arrives. Webhooks are the right answer for anything that runs on a server, and n8n’s Telegram trigger is a webhook with a visual editor around it. This post covers the mechanics, the automations worth building, and a working workflow.
The search results are an automation vendor’s integration page, a list of seventeen bots someone else made, Telegram’s own announcement of chat automation features, and a bot framework on GitHub. None of them explains how a bot actually receives a message, which is the thing that decides whether your automation is reliable, cheap, and hostable. Start there.
Table of contents
- How a Telegram bot actually receives messages
- What is worth automating
- Building it with n8n: the trigger, the logic, the reply
- The details that make it reliable
- Hosting the bot: polling vs webhook decides it
- How this fits the rest of the stack
- FAQ
How a Telegram bot actually receives messages
A bot is an account that cannot log in. It is created by messaging BotFather, which returns a token; the token authenticates every call your code makes to the Bot API. Users message the bot, add it to groups, or press buttons, and each of those events becomes an update: a JSON object Telegram holds for your code to collect.
There are two ways to collect them, and they are mutually exclusive.
Long polling. Your code calls getUpdates in a loop. Each call waits up to a timeout for new updates, returns them, and your code calls again. Simple to start, works from a laptop behind a NAT, and it is what every tutorial uses because it needs no public URL. The costs: the loop must run continuously, only one process can poll a bot at a time, and the latency is whatever the timeout and the loop overhead add up to.
Webhook. You call setWebhook once with an HTTPS URL. From then on Telegram sends each update as a POST to that URL as it happens, and expects a fast 2xx. Nothing runs between messages, several instances can share the work behind one URL, and latency is the network round trip. The requirements: a public HTTPS endpoint with a valid certificate, and a handler that returns quickly and does the slow work afterwards.
The webhook sender post covers the general shape of receiving webhooks reliably, and the same rules apply: acknowledge fast, process asynchronously, and expect retries. For anything hosted, a webhook is the correct choice, and n8n’s Telegram trigger sets one up for you.
What is worth automating
Bots that people keep running fall into a few shapes. Pick one that removes a task you already do by hand.
- Alerts from your systems. A deploy finished, a payment failed, a server is out of disk, a form was submitted. Anything that currently sends an email nobody reads is better as a message in a channel you already look at. This is the highest-value, lowest-effort automation and needs only
sendMessage. - Intake. Support requests, bug reports, leads: a bot in a group collects them with a short conversation and writes them to a spreadsheet, a database or a ticketing tool.
- Commands against your own tools.
/statusreturns uptime,/deploy stagingtriggers a deploy hook,/invoice 42fetches a PDF. A chat is a command line with an audit trail. - Scheduled digests. A morning summary of yesterday’s signups, a weekly report, a reminder. A cron trigger plus
sendMessage. - Content forwarding. A message in one channel republished elsewhere, a file dropped in a chat saved to storage, a link logged to a sheet.
The one to avoid first is the conversational assistant. It is the most tempting and the least likely to be finished, because a conversation has state, and state is where bots get complicated. The inline keyboard post covers what that state management involves in a Python bot. Build the alerts and the commands first; they are done in an afternoon and used every day.
Building it with n8n: the trigger, the logic, the reply
n8n has a Telegram trigger node and a Telegram action node, and between them a workflow is three steps. The n8n workflow templates post is honest that templates are starting points rather than finished products; this is a starting point.
1. Create the bot and store the token. Message BotFather, /newbot, take the token. In n8n, create a Telegram credential with it. Never put the token in a workflow node directly.
2. Add the Telegram trigger. Choose the update types you want, usually message. When the workflow is activated, n8n calls setWebhook with its own public URL for that workflow, which is why n8n itself must be reachable over HTTPS. On a laptop that means a tunnel; on a host it means a domain and a certificate.
3. Route on the message. A Switch node on {{ $json.message.text }} sends /status one way, /help another, and everything else to a default. A Code node or an HTTP Request node does the work: call your API, query a database, format a result.
4. Reply. A Telegram node with the sendMessage operation, chat_id set to {{ $json.message.chat.id }} from the trigger, and the text from the previous step. Use Markdown or HTML parse mode for formatting, and keep replies under the 4096-character limit.
A minimal command handler in a Code node:
const text = $input.first().json.message.text || "";
const chatId = $input.first().json.message.chat.id;
let reply = "Unknown command. Try /status or /help.";
if (text.startsWith("/status")) {
const res = await this.helpers.httpRequest({ url: "https://api.example.com/health" });
reply = `API: ${res.status}, uptime ${res.uptime}`;
}
if (text.startsWith("/help")) reply = "/status - service health
/help - this message";
return [{ json: { chat_id: chatId, text: reply } }];For alerts in the other direction, the trigger is not Telegram at all: a Webhook trigger receives the event from your system, and the Telegram node posts to a channel ID. That workflow is two nodes and is the one most teams build first.
The details that make it reliable
Four things separate a bot that works in a demo from one that runs for a year.
Acknowledge before you work. Telegram retries an update if the webhook does not return 2xx quickly, and a slow handler gets the same message twice. n8n’s trigger responds immediately by default; if you write your own handler, return 200 first and process in a queue or a background task.
Restrict who can talk to it. A bot is public: anyone who finds its username can message it. For command bots, check message.from.id against an allowlist before doing anything with side effects, and for group bots, check the chat.id. Put the allowed IDs in an environment variable, not in the workflow.
Handle the group privacy setting. By default a bot in a group only sees commands addressed to it and replies to its own messages. If the automation needs every message, disable privacy mode in BotFather, and be aware that the bot then sees everything in the group.
Rate limits. Roughly one message per second per chat and around twenty per minute in a group. A digest that sends thirty messages in a burst will be throttled; batch into one message, or space them out.
And one operational habit: getWebhookInfo is the diagnostic call. It reports the registered URL, the pending update count and the last error, and it answers most why-is-my-bot-silent questions in one request:
curl -s "https://api.telegram.org/bot$TOKEN/getWebhookInfo" | jqHosting the bot: polling vs webhook decides it
A polling bot needs a process that never stops: a script on a VPS under a process manager, or a container that restarts. A webhook bot needs an HTTPS endpoint that is up when messages arrive, which is the same requirement, met by a web service instead of a loop.
For a bot written in code, that is a small Node or Python web service. The cheapest way to host a Discord bot post covers the same decision for a bot on a different platform; the arithmetic is identical. A bot that handles a few hundred messages a day idles at almost nothing and fits the smallest plan that keeps a process alive.
For a bot built in n8n, the host is n8n itself. Self-hosting it means a server, a domain, TLS, a database for the workflow state and executions, and upgrades; the n8n Docker Compose example is that setup on a VPS. On RunxBuild, n8n is a managed tool: a create form, a plan, a custom domain with a certificate, and the workflow’s webhook URL is public and HTTPS from the first activation, which is exactly what the Telegram trigger needs. The $6 Basic plan (0.5 vCPU, 624MB) runs a handful of low-traffic workflows; the $13 BasicMini plan (1 vCPU, 1GB) is the comfortable choice once executions stack up, and a managed Postgres beside it keeps execution history off the tool’s own disk. Autoscaling between a floor plan and a ceiling plan covers the day an alert fires four hundred times.
Either way, the bot’s token lives in an environment variable or a credential store, the handler acknowledges fast, and the logs are where you look when a message goes unanswered.
How this fits the rest of the stack
Telegram automation is a token, a webhook and a handler. Use a webhook rather than a polling loop for anything hosted, start with alerts and commands rather than conversations, restrict who the bot listens to, and check getWebhookInfo before anything else when it goes quiet. n8n’s Telegram trigger is that webhook with a visual editor around it. For a sense of what running the workflow engine and the services it talks to costs, the RunxBuild hosting calculator shows the n8n tool, a web service and a managed database as separate line items.
Useful related references:
- Inline Keyboards in a Python Telegram Bot: Callbacks, State, and the 64-Byte Limit
- n8n Workflow Templates: Useful Starting Points, Bad Finished Products
- Webhook Sender: How to Send Webhooks Reliably, How to Test Them, and How to Receive the Ones You Cannot Reproduce
- n8n Docker Compose Example: A Setup That Survives Restarts
- Web Services on RunxBuild
FAQ
How does Telegram automation work?
You create a bot through BotFather, which gives you a token. Your code, or a tool like n8n, receives the bot’s updates, either by polling getUpdates in a loop or by registering a webhook URL that Telegram posts each message to as it arrives. The automation then does something with the message and replies with sendMessage. Webhooks are the reliable choice for anything hosted.
Should a Telegram bot use polling or a webhook?
A webhook for anything running on a server: messages arrive instantly, nothing runs between them, and several instances can share the load. Polling is fine for local development or a script on a machine with no public URL. The two are mutually exclusive; registering a webhook disables getUpdates until you delete it.
Can I automate Telegram with n8n?
Yes. n8n has a Telegram trigger node that registers a webhook for the bot and starts a workflow on each update, and a Telegram action node that sends messages, photos and files. n8n must be reachable over HTTPS for the trigger to work, which means a tunnel on a laptop or a domain and certificate on a host.
Why is my Telegram bot not receiving messages?
Call getWebhookInfo with the bot token; it reports the registered URL, the number of pending updates and the last error. Common causes are a webhook URL that is not HTTPS or not reachable, a handler that returns too slowly so Telegram retries, group privacy mode hiding non-command messages, or a polling process still running elsewhere and consuming the updates.
Is it safe to run a Telegram bot?
The token is the only secret, so keep it in an environment variable or a credential store and rotate it through BotFather if it leaks. Because anyone can message a public bot, check the sender’s user ID or the chat ID against an allowlist before running any command with side effects, and keep the handler from doing slow or expensive work before it has acknowledged the update.