Telegram Broadcast Bot: Limits, Costs and Auto Replies

A broadcast bot is the one piece of Telegram outreach that the platform actually wants you to run. Nothing gets restricted, nobody reports you, and Telegram publishes the limits instead of leaving you to guess them. The catch is at the front door: a bot can only write to people who wrote to it first, and the API will not hand you the list of who those people are. Everything else in this guide follows from those two sentences.

What follows is the running of one: how the list is built, what the published limits actually are, what the paid tier costs and who can reach it, what happens when someone blocks you, and where auto replies fit. If you are still deciding between a bot and a user account, that comparison is a separate piece on choosing a bulk message sender; this one assumes the bot is the answer and gets into the machine.

Every number below is quoted from Telegram's own documentation. Where a figure is ours, measured on our own accounts, it says so.

What a broadcast bot is, and the rule that shapes it

A broadcast bot holds a list of people who have a chat with it and sends the same message to each of them, one request per person. There is no group send in the API. A broadcast of five thousand is five thousand calls, and the interesting work is entirely in the pacing and the bookkeeping.

Who a bot may write to

People who have already opened a chat with it. Someone taps start, or joins a group where the bot is a member, and from then on the bot may write. A bot cannot pick a username off the internet and begin a conversation, and no setting changes that. This is why a broadcast bot is safe: everyone on the list arrived by choosing to.

What a bot is not

It is not a way to reach strangers. If your plan is to message people who have never heard of you, the bot road is closed and the account road is the one you want, with everything that comes with it. Trying to force the bot road there is how people end up buying tools that architecturally cannot do the job.

What changed in 2026: bots that create bots

Asked how to create a bot, Telegram's bot documentation says to set up the account with its bot management bot and then connect it to your backend server, and adds that there are no out-of-the-box ways to create a working bot if you are not a developer. That page is now behind the platform. In March 2026, with Bot API 9.6, Telegram shipped managed bots: a bot can be given permission to create and manage other bots, a single link opens a pre-filled creation screen for whoever receives it, and the managing bot can then fetch the new bot's token through a dedicated method. The current API carries all of it.

So the creation step really is no-code now, and any guide still telling you otherwise is quoting a stale page, including Telegram's own. What has not changed is everything after the token. The thing that stores your subscribers, sends in order, waits when told to wait, retries what failed and answers a keyword at three in the morning is still a server you either write or rent, and no amount of bot-creates-bot changes that.

That is the platform telling you, in its own words, that the token is not the product. The token is an access key. The thing that stores your subscribers, sends in order, waits when told to wait, retries what failed and answers a keyword at three in the morning is a server you either write or rent.

So the real fork is not bot or no bot. It is write the backend or use one that already exists.

Setting the bot up, in the order that matters

The creation part is genuinely five minutes, which is why so many guides stop there and leave the reader stranded at the interesting part.

The token

You create the bot by talking to Telegram's own bot management bot, and it hands you a token. The token is the credential for every request your system will ever make, so treat it like a password rather than a setting: anyone holding it can send as your bot, read what your bot receives and change its profile. If it leaks, the same bot can issue you a new one, and the old one stops working. Whatever holds that token afterwards, your own server or Bot Manager, is the thing that has to keep it safe.

Name, description and the button people see first

The description is what someone reads before tapping start, and it is the only sales copy on this road that reaches a person who has not opted in yet. Say what the bot sends and roughly how often. A description that promises a newsletter collects people who want a newsletter, and those people do not block you later.

Commands, and why the list matters

Setting a command list gives people a menu instead of a blank message box. At minimum you want a start that explains what happens next and a way to stop hearing from you. An unsubscribe command is not a courtesy, it is the pressure valve: without one, the only exit is blocking you, and a block is a worse outcome for both sides.

Deciding what the bot can see in groups

If your bot will also sit in groups, it has a setting that decides whether it receives every message there or only ones addressed to it. Leave it narrow unless you need the rest, since a bot that receives everything is a bot whose logs contain everything.

Building the list, because nobody hands it to you

This is the part that surprises people who assume a bot knows its own audience. It does not, and the API has no method that returns one.

There is no subscriber list endpoint

Look through the method list and you will find ways to ask about a chat, a chat's member count, a specific member of a group, but nothing that returns the set of people who have started your bot. The information exists only as a side effect: when someone writes to your bot, the update carries their chat identifier. If your backend stores it, you have a subscriber. If it does not, that person is gone the moment the update is processed.

The practical consequence is blunt. A bot that has been running for a year without storing chat identifiers has no list at all, and there is no way to recover it. Every broadcast system starts with a table of identifiers, written on first contact.

Where subscribers come from

A start link in your channel description, in a pinned post, in your site footer, at the end of a piece of content. A button on a channel post. A bot that answers something useful, so that opening it has a reason beyond signing up for messages. Each of these produces a person who chose to be on the list, which is the whole advantage of this road.

What to store beyond the identifier

The date they arrived, where the link came from, the language they use, and whatever your bot learned from the conversation. A broadcast to everyone is the crudest possible use of a list you built one person at a time. Segments make the same list produce better numbers without sending a single extra message.

The limits Telegram publishes

Three numbers, stated plainly in Telegram's own bot documentation, and worth memorising because almost every article on this subject gets at least one of them wrong.

One message per second in a single chat

Telegram advises against sending more than one message per second to the same chat. This one rarely binds during a broadcast, since a broadcast sends one message to many chats rather than many to one. It binds when a bot is chatty in a conversation, which is a different bug.

Twenty messages per minute in a group

A bot cannot send more than twenty messages per minute in a group. If your bot posts to groups as well as private chats, this is the number that will catch you, and it is far lower than people expect.

About thirty messages per second in bulk

For bulk notifications, a bot cannot broadcast more than about thirty messages per second. That is the number that governs a broadcast, and it is generous: thirty a second is one hundred and eight thousand an hour. A list of ten thousand goes out in under six minutes if nothing else slows you down.

Telegram's own advice for anyone who does not want to pay for more is to spread the sending over longer intervals, which is also better practice for other reasons covered further down.

Paid broadcasts, and the gate in front of them

Telegram sells a higher ceiling, and the terms are specific enough that you can decide in one minute whether it applies to you.

What it buys

Enabling paid broadcasts through the bot management bot raises the limit to a thousand messages per second. Each message above the free thirty per second costs a tenth of a Star, taken from the bot's own Star balance. Telegram notes that bots with increased limits are charged only for messages that are broadcast successfully, so a failed send is not a billed send.

Who can actually enable it

To turn the feature on, Telegram requires the bot to hold at least one hundred thousand Stars on its balance and to have at least one hundred thousand monthly active users. Read that twice before anyone quotes paid broadcasts to you as an option. It is a tier for an application with a national footprint, not for a business growing a list.

What to do instead

Spread the send. Thirty per second is the free ceiling and it is not the bottleneck for any list under a few hundred thousand people. If your broadcast feels slow, the fix is almost always to start it earlier rather than to pay for speed you cannot qualify for.

When someone blocks your bot

This is the one failure mode unique to the bot road, and it is the healthiest signal you will get.

How you find out

Telegram sends your bot an update when a member's status changes in a chat, and for private chats that update arrives specifically when the bot is blocked or unblocked by the user. So a blocked subscriber is not a mystery you infer from failures; it is an event you can record the moment it happens.

Why it matters more than the number suggests

A block is a person telling you the messages were not worth having. Blocks concentrate around a particular broadcast, and if you record which one was in flight you get an answer no survey would give you. A rising block rate after a specific message is the message's verdict.

What to do with blocked subscribers

Mark them and stop sending. Continuing to attempt delivery to people who have blocked you wastes your rate allowance on requests that cannot succeed, and it inflates your delivery figures with attempts that were never going to land. A clean list is faster and more honest at the same time.

Flood control, and the polite way to handle it

Send too quickly and Telegram tells you to wait. The API's error response carries a field giving the number of seconds left to wait before the request can be repeated.

The only correct response

Wait exactly that long, then continue. A system that treats this as a hard failure and retries immediately turns one pause into a pattern, and a system that gives up drops the rest of the list. Neither is necessary: the platform is telling you precisely what it wants, in seconds.

Design the queue for it

A broadcast should be a queue that can pause and resume, not a loop that runs to completion or dies. That single design choice is the difference between a broadcast that survives a restart, a network blip and a flood wait, and one that has to start again and sends some people the same message twice.

Auto replies, and where they actually live

The second half of what people mean when they search for a broadcast bot is the part that answers without you.

What Telegram gives you

Updates. Your bot receives incoming messages either by long polling or by a webhook, and what happens next is entirely your code. There is no keyword rule builder in the API, no menu of canned answers, no working hours switch. The platform delivers the message and steps back.

What a useful auto reply layer contains

Keyword matching that is not case sensitive and tolerates the way people actually type. A default answer for everything that matches nothing, because silence reads as broken. A way to hand off to a human, since the value of an auto reply is filtering, not pretending. And a record of what people asked, which over a month is the cheapest customer research available to you.

Why this pairs with broadcasting

A broadcast generates replies. If nobody is reading them, the broadcast has produced a pile of unanswered messages and an impression of a company that talks and does not listen. Broadcasting without a reply path is the most common way a good list gets spent.

Timing, and the case for going slower

You can push a list of ten thousand out in six minutes. There are two reasons not to.

Replies arrive in a wave

Everyone gets the message at once, so everyone answers at once. If one person handles replies, a six minute broadcast produces a queue that takes the rest of the day, and the people at the back wait so long that the reply is no longer relevant. Spreading the send spreads the answering.

The hour matters more than the speed

A message at three in the morning is read late, answered by fewer, and blocked by more. Sending by local hour rather than by server clock costs one field in your subscriber table and changes your numbers more than any pacing tweak. Our note on when to post on Telegram goes through the evidence.

What a broadcast should contain

The limits are the easy half. The message is the half that decides whether the list survives the year.

One thing per broadcast

A broadcast carrying three announcements gets read as none. The person is in a messaging app, not an inbox, and the attention you have is one screen deep. Pick the thing that matters and send the others another day, since sending costs you nothing except the goodwill you spend.

A reason this arrived

People forget they started your bot. One clause reminding them why they are hearing from you removes most of the confusion that turns into a block.

Something to do

A broadcast with no next step is an announcement, and announcements train people to skim. Even a question works, because a reply opens a conversation and conversations are where the bot road earns its keep.

Frequency, honestly

Nobody publishes a correct number and neither will we. What is measurable is your own block rate: if it rises with frequency, you have found your ceiling, and it is specific to your list rather than to Telegram.

Measuring a broadcast

Four numbers, and volume is not one of them.

Collect these per broadcast rather than in total. A running average across a year hides the single message that cost you two hundred subscribers, and that message is the only thing in the whole set you can actually learn from.

Delivered

Attempts that succeeded. On the bot road this should be very high, because everyone on the list chose to be there. A low figure means your list has gone stale or you are still attempting people who blocked you.

Blocked

The clearest verdict you get, and the reason to record which broadcast was in flight when each block arrived.

Replies

The number that predicts revenue on this road as much as on any other. A broadcast that produces conversations is doing the job; one that produces silence is a newsletter nobody asked for.

Time to answer

How long a reply waits. This is the number most teams never look at, and it quietly decides whether the conversations that started turn into anything.

What actually breaks in real broadcasts

Four failures, in the order you will meet them, and all four are bookkeeping rather than platform problems.

The run that stopped halfway

A restart, a deploy, a crash. If the queue only remembers what it has attempted, resuming sends the first half twice; if it remembers nothing, half the list never hears from you and you cannot tell which half. Recording each send as it succeeds, rather than counting a loop, is the fix and it costs one column.

The same person twice

Someone who started your bot from two links, or whose identifier was stored twice on different days, is one person and two messages. This is the same duplication that inflates a scraped list, and the honest number is unique identifiers rather than rows in a table.

The message that could not render

A broadcast with formatting in it will fail for the individual message when the formatting is wrong, not for the run. A system that logs the run as finished while quietly dropping the failures gives you a delivery figure that is not a delivery figure. Failures need a reason attached to be worth anything.

The reply nobody saw

The most expensive of the four. Replies arrive as ordinary updates, and if the system that sends is not the system that reads, they sit unread. A broadcast that produced forty replies and no answers is worse than one that produced none, because forty people now know you do not read.

How to tell before it matters

Send to yourself and four colleagues first. Kill the process halfway and restart it. That two minute test answers the resume question, the duplicate question and the reply question at once, and it costs nothing compared to finding out on ten thousand people.

When the bot road is the wrong road

Being honest about this saves people money, including money they might otherwise spend with us.

If the people you want have never contacted you, a bot cannot reach them and no tool changes that. That job runs on user accounts, with reports, restrictions and pacing to think about, which is the subject of the sender comparison and of our guide to keeping accounts alive in cold outreach.

If your audience is a channel rather than a bot, broadcasting is just posting, and the tooling question becomes one of scheduling and content instead. And if what you actually need is moderation, that is a third thing again: a group keeper like the ones covered in our Combot guide does a job no broadcast system does.

Running one without writing the backend

Telegram says a working bot needs a developer, and for a bot with custom logic that is still true. For the two jobs in this article, storing subscribers and broadcasting to them, plus answering keywords, it no longer has to be.

Bot Manager connects the bot you already made with the bot management bot and provides the parts Telegram leaves to your backend: the subscriber table filled as people arrive, broadcasts that pace themselves inside the published limits and resume rather than restart, keyword auto replies you write in a form, and one shared inbox so replies land somewhere a team can see them rather than in a script's output.

What it does not do is raise a limit, because nothing does, and it does not reach people who never started your bot, because nothing on this road can. Tiers are on the pricing page, and a demo opens from inside the dashboard.

A short checklist before your first broadcast

Are you storing chat identifiers on first contact, and since when? Do you know how many people are actually on the list, as opposed to how many ever opened the bot? Does your sender pause on a flood wait and resume, or does it die? Are blocked users excluded? Is there a reply path, and does somebody watch it? Are you sending by the reader's hour or by your server's? And can you tell, afterwards, which broadcast produced the blocks?

Seven questions. A system that answers all seven will outperform a faster one that answers none of them, because on this road speed was never the constraint.

Frequently Asked Questions

Can a Telegram bot message users who never started it?

No. A bot can write to people who already have a chat with it, which means they tapped start or joined a group where the bot is a member. This is the design of the Bot API rather than a limit that can be raised, so any tool promising bot based cold outreach is describing something the platform does not do.

How many messages can a Telegram bot send per second?

Telegram publishes three figures: no more than one message per second in a single chat, no more than twenty messages per minute in a group, and no more than about thirty messages per second for bulk notifications. The thirty per second figure is the one that governs a broadcast, and it works out to roughly one hundred and eight thousand messages an hour.

How do I get the list of my bot's subscribers?

You store it yourself. The Bot API has no method that returns the people who have started your bot; you learn a person's chat identifier when they send a message, and if your backend does not record it at that moment the information is gone. A bot that has run for a year without saving identifiers has no list to broadcast to.

What do paid broadcasts cost and who can use them?

Paid broadcasts raise the ceiling to a thousand messages per second, at a tenth of a Star for each message above the free thirty per second, charged only for messages that broadcast successfully. To enable the feature, Telegram requires the bot to hold at least one hundred thousand Stars and to have at least one hundred thousand monthly active users, which puts it out of reach for most businesses.

What happens when a user blocks my bot?

Telegram sends your bot an update when a chat member's status changes, and for private chats that update arrives specifically when the bot is blocked or unblocked. Record it, stop sending to that person, and note which broadcast was in flight, because blocks cluster around the message that caused them.

What should I do when I hit a flood limit?

The error response tells you how many seconds are left before the request can be repeated. Wait that long and continue. Retrying immediately makes the pause worse, and abandoning the run drops the rest of your list, so the queue should be able to pause and resume rather than run to completion or die.

Does Telegram provide keyword auto replies?

No. The platform delivers incoming messages to your bot through long polling or a webhook, and everything after that is your own code. Keyword matching, default answers, working hours and handing a conversation to a person are all things you build or rent, not settings you switch on.

Do I need to be a developer to run a broadcast bot?

Not any more for the creation step. Telegram's bot documentation still says there are no out-of-the-box ways to create a working bot without a developer, but that page predates managed bots, shipped in March 2026, which let one bot create and manage another with no code at all. What still needs building or renting is the part after the token: storing subscribers, pacing a broadcast inside the published limits, and answering keywords.

How often should I broadcast?

Nobody can give you a correct number, and any that you find quoted is one person's experience. The measurable answer is your own block rate: raise frequency until it starts to climb, and you have found the ceiling for your list rather than for Telegram.

Is a broadcast bot safer than sending from an account?

Yes, and by a wide margin. Everyone on a bot's list chose to be there, the limits are published rather than inferred, and there is no restriction to appeal because there is nothing to restrict. The trade is reach: a bot cannot start a conversation, so it is the right tool for an audience you already have and the wrong one for an audience you want.