Telegram bots cannot start a conversation. The platform enforces it

Telegram writes the rule down. A bot on Telegram cannot start a conversation: the user has to act first, by writing to it, adding it to a group, or granting it write access through a menu or a Web App. That is not a policy a vendor chose and it is not a throttle you can pay to lift. It is stated in Telegram’s own developer documentation, on a platform Telegram describes as “free for both users and developers”. What the rule governs is that first contact. Once a user has acted, Telegram documents messaging them and even broadcasting to them.

The sentence, and where it is

The statement is on Telegram’s introduction for developers, in the section comparing bots to normal user accounts:

Bots can’t start conversations with users. A user must either add them to a group or send them a message first. People can search for your bot’s username or start a chat via its unique t.me/bot_username link.

Three things are worth separating out of that. What the sentence forbids is starting the conversation, and it forbids it flatly: not delayed, not rate-limited, not priced. The two openings it names are both the user’s move, a private message or a group invite. And the discovery route Telegram names, a username search or a t.me link, gets the user to the chat without the bot reaching out.

Read it as a rule about first contact, which is what it says, rather than as a permanent reply-only regime, which it does not say. The section below on authorised messaging is the other half of it.

We read three Telegram pages for this article and the sentence appears on one of them. It is not in the Bot API reference, which describes itself as “The Bot API is an HTTP-based interface created for developers keen on building bots for Telegram”, and it is not in the Bots FAQ, which has a whole section headed Broadcasting to Users and never states it. If you went looking for this rule in the API docs, as a developer reasonably would, you would not find it. That is worth saying plainly, because the rule is real and the FAQ’s silence on it is easy to misread as permission.

What the API reference does say

The Bot API reference never gives a bot a way to reach somebody who has done nothing, and two of its notes only make sense if the rule holds. A third field on the same page records the user granting write access, and that one has its own section below.

Mentioning a user by numeric ID is conditional. The reference says such mentions are only guaranteed to work if “the user has contacted the bot in private in the past” or has sent a callback query to the bot through an inline button. Prior contact by the user is the precondition, written into a formatting note.

The one opening the reference documents is tiny and time-boxed. On a chat join request, the bot receives a private chat identifier for the user, and Telegram says the bot can use it “for 5 minutes to send messages until the join request is processed”, adding the qualifier “assuming no other administrator contacted the user”. That is the exception proving the shape of the rule: a few minutes, granted by an action the user took, expiring on its own.

Telegram applies the same logic to bots talking to bots, for a reason it states rather than implies: “Bots talking to each other could potentially get stuck in unwelcome loops.” The platform is comfortable removing a capability outright when the failure mode is obvious.

Free is the part worth noticing

The interesting thing is not that Telegram restricts bots. It is that Telegram restricts the message nobody asked for while leaving the wanted ones free. From the FAQ: “bots are able to message their users at no cost”, subject to throughput limits that are published as plainly as the prohibition.

Limit, quoted from the Bots FAQ
“In a single chat, avoid sending more than one message per second.”
“In a group, bots are not be able to send more than 20 messages per minute.”
“For bulk notifications, bots are not able to broadcast more than about 30 messages per second, unless they enable paid broadcasts to increase the limit.”

The slipped grammar in the second row is Telegram’s, kept because the rows are quoted rather than tidied.

There is a paid tier, and reading what it buys is instructive. “Enabling paid broadcasts in @BotFather allows a bot to broadcast up to 1000 messages per second.” The cost is per message: “Each message broadcasted over the free amount of 30 per second incurs a cost of 0.1 Stars per message”, and the eligibility bar is that a bot “must have at least 100,000 Stars on its balance and at least 100,000 monthly active users”. Money buys throughput to users who already started the chat. It does not buy the first message. The one rule that cannot be paid around is the one about permission.

Unsolicited first contact is the thing barred, not outbound messaging

This is the distinction to get right, and it is the one most summaries of Telegram’s rule lose. Telegram bars the bot from opening a conversation. It does not bar a bot from messaging users afterwards, and two of its own pages document the opposite.

The Bots FAQ has a section headed Broadcasting to Users, and the question in it is “How can I message all of my bot’s subscribers at once?”. Its answer is about rate limits and paid broadcasts, not about whether you may. The permission sentence in the same section is bounded on the front rather than the back: “By default, bots are able to message their users at no cost - but have limitations on the number of messages they can broadcast in a single interval”.

The Bot API documents a second way write access arrives, and it is not a message from the user at all. A Message can carry a write_access_allowed field, which Telegram describes as a “Service message: the user allowed the bot to write messages after adding it to the attachment or side menu, launching a Web App from a link, or accepting an explicit request from a Web App sent by the method requestWriteAccess”. Adding a bot to a menu, opening a Web App or granting an explicit request are all the user’s acts, and each of them authorises writing without the user having sent a message.

So the accurate shape of Telegram’s rule is a gate on the first contact plus a standing permission afterwards, granted by something the user did, with published throughput limits and an optional paid tier on top of it. Our own rule is stricter than that: mesej is specified to answer and not to broadcast, which is a product choice we made and not a description of what Telegram permits. Specified rather than built: there is no Telegram integration here and nothing to connect, so nothing of ours has answered a Telegram message.

WhatsApp is the near miss, not the parallel

It is tempting to say WhatsApp works the same way. It does not, and the difference matters more than the resemblance.

Meta’s documentation defines a window rather than a prohibition:

When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts. If the user messages or calls you again before the timer expires, the timer resets to 24 hours.

Inside that window a business writes freely, and Meta notes that unlike templates, “service messages do not require pre-approval”. Outside it there is still a route: “Template messages are the only type of message that can be sent to WhatsApp users outside of a customer service window.” Templates are approved in advance and they are the billable object, since on Meta’s pricing page “You are only charged when a template message is delivered”.

So the two platforms agree that something the user does is what unlocks writing freely, and they disagree about what happens before it. WhatsApp’s answer is a pre-approved, paid template, which is a route to a stranger. Telegram’s answer is that the bot cannot start the conversation at all, and it offers no paid route around that. What Telegram does offer, once the user has acted, is standing write access rather than a repeating 24-hour clock: WhatsApp’s permission expires and has to be reopened by the customer, and we found nothing on the three Telegram pages cited below that puts a clock on a bot’s access to its own users once they have written to it or granted it. Neither platform is reply-only in the sense a vendor means it. The difference is where each one puts the gate, and anyone who tells you the two are the same rule has read one of them.

What this means for a bot you are about to set up

There is no Telegram integration here and nothing to connect, and mesej never messages anyone first, which is stricter than Telegram: the platform permits messaging users who have authorised the bot, and we do not do that.

If you are setting one up, the rule above decides the entry route and nothing else. What a bot can actually do once the customer has started the chat, from the t.me link and the Start button to commands, the two kinds of keyboard and the file size limits, is in what a Telegram bot can do for a business that answers messages.

What we have not verified

We read documentation, not behaviour. We have not run a bot against the Bot API to observe what error a send to a stranger returns, and we are not going to describe an error message we have not seen. We also found no definition on those three pages of what counts as one of a bot’s own users or one of its subscribers, beyond the three routes quoted above: a private message, a group invite, and the grant recorded by write_access_allowed. Whether write access granted that way can be withdrawn short of a block is not something we found either. What is documented is the rule itself, on Telegram’s own site, in one sentence: bots can’t start conversations with users.