Building a Telegram Bot with n8n: From Notifications to Conversations

Telegram is the most common interface to automation: no website to build, no new tool to explain to anyone. A bot comes together quickly in n8n, but between “it replies to a message” and “it works for real users” sit a few steps worth taking deliberately.

Connecting

Get the token from BotFather and store it in n8n credentials. The entry point is the Telegram trigger: on activation n8n registers the webhook address with Telegram itself, so there is nothing to configure separately.

The requirement is the same as for any webhook: a public HTTPS address. A local n8n without a domain will not work - Telegram has nowhere to deliver updates. How to stand that up is covered in installation.

This is where the classic mistake begins: built on the test URL, everything worked, closed the editor, bot went silent. The production address only lives on an activated workflow.

What actually arrives

Telegram does not send “the message text” but an update object with everything attached: who wrote, in which chat, what exactly, and whether it was text, a photo, a command or a button press.

Two practical consequences:

• Check the type. A bot expecting text that receives a sticker fails on a missing field - the same data shape problem as everywhere else.
• chat.id is your key identifier. You need it to reply, and it doubles as the state key. Do not confuse it with the user id: in a group they are different things.

Commands and buttons

Commands (/start, /help) are ordinary text beginning with a slash, parsed by branching. Register the command list with BotFather so users get a hint instead of guessing.

Inline buttons beat commands almost always: fewer input mistakes and a clearer flow. One important detail - a button press arrives as a different update type than a message. The workflow must handle both, and this is the first thing forgotten when a bot suddenly “ignores the buttons”.

A second nuance: Telegram expects an acknowledgement for a button press. Without it the user is left with a spinning indicator - a small thing that reads as broken.

Conversation state

The key constraint: n8n does not keep state between runs. Every message is its own execution and knows nothing about the previous one.

For linear flows (received, replied) that does not matter. The moment you have a multi-step dialogue - “enter your email”, then “enter your company” - state must live outside, keyed by chat.id: a database, a sheet, or the memory of an AI agent if the flow is conversational.

On agent memory specifically: the session key must be the chat identifier. Skip that and every user shares one context and reads other people’s conversations.

Groups and channels

In a group a bot does not see all messages by default, only those addressed to it - a privacy setting in BotFather. If a bot “stays quiet” in a group, check that first.

For a channel the bot must be an administrator. And remember the difference: posting to a channel is one-way, there is no conversation there.

Telegram’s limits

Two limits that bite as you grow:

Send rate. A broadcast to a list runs into rate limits and Telegram starts returning errors. Since a node runs once per item, a thousand-recipient broadcast is a thousand consecutive calls. You need pauses between sends and retries with backoff on rejection.

Message formatting. If you use markup, special characters inside user-supplied data break it and Telegram rejects the whole message. Either escape interpolated text or do not format anything that came from a user.

Before production

• Answer unexpected input. A sticker, a photo, an empty message, an unknown command - the bot should say something rather than nothing.
• Acknowledge slow operations immediately. If the workflow takes 20 seconds, send “got it” first: a silent bot looks broken.
• Alert yourself on errors. An error workflow is mandatory here: with a bot, users see the failure before you do.
• Test with a second user. State and shared-memory bugs only appear once more than one person is involved.