How to Create a Telegram Bot and What It Will Not Do

Making a Telegram bot takes about five minutes. You message BotFather, you pick a name, you pick a username, and a token comes back. Nothing about that process suggests you have just hit a ceiling, because you have not built anything yet. The ceilings arrive later, usually on the day somebody decides the bot should message a few thousand people, and by then a fair amount of work has been done on the assumption that it could.

None of those limits are hidden. They are published, they are specific, and most of them are numbers rather than vague guidance. A bot may send about one message a second into a single chat, twenty a minute into a group, and thirty a second in bulk. Past that there is a paid tier with a price per message. Privacy mode decides what the bot is even allowed to read. And there is a quiet access rule underneath all of it which decides who your bot may talk to at all.

This article covers the whole thing in order. What a bot is in Telegram's own words, what the five minute setup actually gives you, the two choices you cannot undo afterwards, all four rate walls with their numbers, what privacy mode does and does not cover, the file and command ceilings, the two ways of receiving updates and why you cannot use both, and what all of it adds up to before you commit anybody's time. Every limit, refusal and sentence quoted below was pulled from Telegram's own bot documentation on 9 August 2026 rather than remembered.

What a Bot Actually Is

Telegram's own definition

The introduction page is short and worth taking literally. Bots are described as small applications that run entirely within the Telegram app, which users interact with through flexible interfaces that can support any kind of task or service. Note what that sentence does not say. It does not say a bot is an account, and it does not say a bot is a way to reach people.

It is an application, not a user

That distinction is the root of everything below. A bot is a program you host somewhere, connected to Telegram through an interface, responding to things that happen. It occupies a slot that looks like a user in the interface, which is why people expect it to behave like one, and almost every surprise in this article comes from that expectation being wrong.

Two interfaces, not one

There are actually two ways to drive a bot. The simplified interface most people mean when they say bot, and the underlying protocol which the documentation describes as also usable for bots. The simplified one is easier and carries most of the limits described here. Knowing there are two is useful mainly so you understand that a tool doing something your bot cannot is not necessarily cheating.

The simplified interface also has a self hosted variant with looser limits, which the documentation mentions for the minority of bots that need it. Most projects are fine on the shared servers, and the note is there so nobody assumes a ceiling is absolute when it is really a property of where the interface is running. Reaching for that is a real decision with real hosting attached, not a setting.

Making One Takes Five Minutes

The whole process

You talk to BotFather, which is itself a bot, you give a name and a username, and you get a token back. That is the entire creation step. There is no approval, no review, no waiting period and no cost. The ease of it is genuine and it is also the source of the misunderstanding, because creating the account is not the part that takes work.

Two things do get decided in that conversation that are worth slowing down for. One is the description shown in the box titled what can this bot do, which is the first thing a new user reads and the last thing most builders write. The other is the profile media. Neither is difficult and both are usually left until after somebody has already shared the link.

What Telegram says about the rest

The frequently asked questions page is blunt about what happens next. It says creating bots is easy but that you will need at least some skills at computer programming, and that in order for a bot to work you set up the account with BotFather and then connect it to your own backend server through the interface. The bot is a front end for something you have to build and run.

The sentence most people never read

The same page then says, in its own words, that unfortunately there are no out-of-the-box ways to create a working bot if you are not a developer. That is Telegram writing about its own platform, not a competitor. If you have been told that a bot is the easy path to automated messaging, the platform disagrees with whoever told you.

The Two Choices You Cannot Undo

The username is permanent

The documentation is direct about this. Unlike the bot's name, the username cannot be changed later, so choose it carefully. The name shown at the top of the chat can be edited whenever you like. The address people type and link to is fixed at creation, forever, on a decision made in the first two minutes.

The rules on that username

Usernames are five to thirty two characters, not case sensitive, and may only contain Latin letters, numbers and underscores. On top of that, a bot's username must end in the word bot. So every option you actually have is shorter than it looks, and the good ones went years ago, which is worth knowing before you spend an afternoon on branding.

Why this matters more than it sounds

Because the username is what goes in every link, every mention, every printed reference and every deep link you ever create. Changing your mind means a new bot, a new token, and everybody who saved the old one landing somewhere dead. Treat it the way you would treat a domain rather than a label.

There is a related detail that catches teams rather than individuals. Inline functionality has to be enabled through BotFather or the bot simply will not receive those updates at all. So a feature can be fully written, deployed and correct, and produce nothing, because a switch in a chat window was never flipped. Check the switches before debugging the code.

Interfaces are the other thing decided early and regretted later. A bot can answer with commands, with a keyboard that replaces the user's own, with buttons attached to its messages, or with a full custom screen written in the usual web languages. Those are four different amounts of work and four different maintenance stories, and picking the heaviest one first is how small projects stop being small.

The Token Is the Whole Account

What it looks like and what it does

The token is a string in a documented format, a numeric identifier joined to a long secret. The documentation says plainly that it is required to authorise the bot and send requests, that you should keep it secure and store it safely, and that it can be used by anyone to control your bot. There is no second factor and no separate password.

There is no recovery story, only replacement

Since the token is the entire credential, a leaked token is a compromised bot, and the answer is to revoke and reissue rather than to change a password. Anything holding the old token stops working at that moment, which is fine on a small project and a real incident on a live one. Plan where the token lives before you paste it anywhere.

A small detail that trips people constantly

When sending a request, the documentation reminds you to prefix the word bot to your token in the address. It is a two word note in the middle of a long page and it is responsible for a good share of the first hour anybody spends on this. If nothing works and everything looks right, check that prefix.

The same page is worth reading once end to end for exactly this reason. The bot documentation is not organised around the mistakes people make, it is organised around the features, so the sentence that saves you an afternoon is usually a clause inside a paragraph about something else. Reading it in order once is cheaper than searching it twelve times.

The First Wall: One Message a Second

The number and the consequence

In a single chat, the documentation says to avoid sending more than one message per second. It adds that short bursts over that limit may be allowed, but that eventually you will begin receiving errors. Not a warning, not a slowdown, an error response your code has to handle.

The response carries a wait

When flood control does trigger, the response includes a field giving the number of seconds left before the request can be repeated. That is a genuinely helpful design, and it is also the thing most first attempts ignore. A retry loop that does not read that number turns a one second pause into an escalating problem.

Why this is the wall that surprises people least

Because one message a second into one conversation is a lot of messages by any human standard. Nobody hits this by talking to a person. It is hit by loops, by retries after a failure, and by two parts of the same system both deciding to reply. If you are seeing it, the shape of the problem is usually duplication rather than volume.

It is also worth knowing what a single message may carry, since the answer to a rate limit is often fewer and larger messages. Text runs to four thousand and ninety six characters after formatting is applied, which is a long way past anything anybody should send in one block, but it does mean that splitting a message into three for readability is a choice rather than a requirement.

The Second Wall: Twenty a Minute in a Group

The number

In a group, the documentation says bots are not able to send more than twenty messages per minute. That works out at one message every three seconds, which is dramatically tighter than the private chat allowance and catches people who assumed the limits scaled up rather than down as the audience grew.

What it rules out

It rules out the most common group bot idea, which is greeting or replying to everybody individually in a busy room. Twenty a minute is fine for a moderation bot answering occasional commands and completely inadequate for a bot that reacts to every join in a group that is growing quickly. Our notes on what actually happens when you add members at speed come at the same ceiling from the other direction.

The design that gets around it

The way out is not a faster bot, it is fewer messages. One pinned message instead of a greeting per person, one summary instead of a reply each, buttons instead of conversation. Every well behaved group bot you have used is built this way and it is a constraint that improves the result rather than compromising it.

There is one more group restriction with no workaround at all. Bots cannot use invite links generated by other administrators, so a bot that manages joining has to work with links it created itself. Anybody building group automation around a link somebody else made will find that out at the point of deployment rather than the point of design.

A bot can also propose the administrator rights it wants when it is added to a group or channel, which is a small courtesy that saves an argument later. Asking for exactly what the job needs, and no more, is the difference between a bot people keep and one somebody removes the first time they audit the member list. Ask narrowly and the answer is usually yes.

The Third Wall: Thirty a Second in Bulk

The number that decides most projects

For bulk notifications, the documentation says bots are not able to broadcast more than about thirty messages per second. This is the one that matters commercially, because it is the ceiling on the single most common reason people want a bot in the first place, which is telling a lot of people something at once.

What thirty a second means in practice

It means a thousand recipients takes a little over half a minute, ten thousand takes about five and a half minutes, and a hundred thousand takes nearly an hour of continuous sending. Whether that is a problem depends entirely on whether the message is time sensitive. For a daily digest it is irrelevant. For anything tied to a moment, an hour of drift is the whole story.

The arithmetic also decides your architecture. Sending for an hour means a process that survives an hour, retries safely, and knows where it stopped if it dies halfway. That is a queue, not a script, and it is the point where most weekend projects turn into real software. Deciding that before you start is much cheaper than discovering it during your first large send.

Bulk means to your own subscribers

Worth being exact, because this is where people get the wrong idea. The limit governs messaging users of your bot, meaning people who have already started a conversation with it. It is not a channel for reaching strangers, and no amount of paid tier changes that. The outbound side of that problem is a different mechanism entirely, which is what sending direct messages at scale is about.

Buying Your Way Past the Third Wall

There is an official paid tier

Enabling paid broadcasts through BotFather allows a bot to broadcast up to a thousand messages per second. That is a genuine thirty fold increase and it is offered by the platform rather than worked around, which makes it the only sanctioned answer to the bulk problem.

The price is published per message

Each message broadcast over the free allowance of thirty a second costs a tenth of a star, paid from the bot's own balance. That is unusually transparent pricing for a rate limit, and it means the cost of a large send is arithmetic rather than a negotiation. If you are not already familiar with that currency, how stars are earned, spent and withdrawn covers it.

What this tells you about the platform's view

Read the design rather than just the price. Telegram has decided that high volume automated messaging is legitimate, that it should be metered, and that the meter should be attached to the bot's own balance. Anybody planning volume should build the per message cost into their numbers from the start rather than discovering it at the point of sending.

It also gives you a clean way to compare options. Once the platform itself prices a message, any tool or service can be measured against that number rather than against a feeling. If something costs more than the official meter and does not do more than the official meter, you have your answer, and if it does something the meter cannot reach at all then you are not comparing the same thing.

Privacy Mode Decides What Your Bot Can Read

It is on by default

Privacy mode is enabled by default for every bot, with one exception the documentation names. Bots added to a group as administrators always receive all messages. So the answer to what your bot sees in a group depends on how it was added, before anything you configure.

Turning it off has a catch

It can be disabled so the bot receives all messages like an ordinary user, but the documentation adds that the bot will need to be re-added to the group for the change to take effect. That is the single most common reason a setting looks like it did not apply. The switch flipped and the group did not, because the group is still running the old arrangement.

The recommendation attached to it

The documentation only recommends disabling privacy mode where it is genuinely required, and the reasoning is obvious once stated. A bot with privacy mode off is reading everything everybody says in that room. That is a large amount of trust to ask for, and members can see the arrangement, so it is worth being able to justify.

There is a narrower permission worth knowing before you turn everything off. To receive reaction updates the bot must be an administrator and must explicitly ask for that update type in its configuration. So some things people assume are blocked by privacy mode are actually blocked by not having been requested, and the fix is a list rather than a switch.

What a Bot Sees Regardless of Privacy Mode

Three categories always arrive

Even with privacy mode on, the documentation says a bot receives all service messages, all messages from private chats, and all messages from channels where it is a member. So privacy mode is narrower than people assume. It restricts what a bot overhears in group conversation, not what reaches it everywhere.

Bots never see other bots

There is a categorical rule with a stated reason. Bots will not be able to see messages from other bots regardless of mode, and the documentation says this was decided deliberately to avoid a particular failure. Two bots that reply to each other produce a loop nobody can stop from inside, so the platform removed the possibility.

Why that rule costs you a design

It means you cannot chain bots in a group by having one respond to another's output, which is the first architecture most people reach for when combining two tools. Whatever coordination you need has to happen on your own server, between your own components, before anything is sent. That is a better design anyway, but it is not the obvious one.

The one exception the documentation now describes is narrow and opt in on both sides, which proves the rule rather than softening it. Two bots can exchange messages only where both have deliberately enabled it. Nothing about that helps the usual case, where somebody wants a general purpose bot to react to whatever another tool posts in a shared room.

A Bot Can Only Act on People It Already Knows

The documented form of the rule

This is the constraint most often repeated incorrectly, so here is the actual wording. The documentation notes in several places that the bot may not have access to a user or chat and could be unable to use an identifier, unless that user or chat is already known to the bot by some other means. An identifier alone is not permission.

What that means when you hold a list

It means a spreadsheet of user identifiers is not an audience. Your bot can only reliably act on people who have arrived at it through Telegram, by starting it, by being in a shared group, or by some other path that made them known. This is the wall behind every question about why a bot cannot simply message a purchased list.

The honest note on what is not documented

The common phrasing that a bot can never write to somebody first does not appear in these pages in that form, and I am not going to quote a sentence that is not there. What is documented is the access rule above, which produces the same practical result by a different route. If you need contact with people who have never met your bot, the mechanism is not a bot at all, which is the point of the direct message product.

Commands Are Tighter Than They Look

The format is narrow

A command is one to thirty two characters and may contain only lowercase English letters, digits and underscores. Its description runs one to two hundred and fifty six characters. No capitals, no accented letters, no hyphens. Anybody naming commands in a language that is not English discovers this immediately.

A hundred commands, and scopes

A bot may register at most a hundred commands, and the list can be set per scope so different users see different menus. The documentation gives the example of showing additional commands to group administrators. A bot with one flat list of everything for everybody is leaving that entirely unused.

The documentation also states a requirement rather than a suggestion, saying all developers are required to support several global commands so that bots offer a consistent experience. That is the reason every competent bot answers the same two or three basics no matter what else it does. Skipping them is not a stylistic choice, it is ignoring a stated rule.

Language is a first class field

Command lists also take a two letter language code, and if it is empty the commands apply to everyone in that scope. So translation is not something you bolt on by detecting language and switching strings, it is a property of the registered list. That is worth knowing before you build the switching yourself.

Files Have Their Own Ceilings

Twenty megabytes down, fifty up

The maximum file size a bot can download is twenty megabytes. Going the other way, uploads are capped at ten megabytes for photos and fifty for other files. Those are two different numbers in two different directions and neither is generous by modern standards, which catches anybody planning to move video through a bot.

Download links expire

A file link is valid for at least an hour, and when it expires a new one can be requested. So a stored link is not a stored file. Any system that saves the address and comes back to it a day later will find nothing there, and the fix is to store the identifier and ask again rather than to cache the link.

Identifiers are not interchangeable

Two more rules save real time. It is not possible to change the file type when resending by identifier, so a video cannot be sent as a photo. And there is a second, unique identifier which is stable across bots and over time but explicitly cannot be used to download or reuse the file. One is a handle, the other is a fingerprint.

Inline results have their own ceiling that catches search style bots early. No more than fifty results are allowed per query, which is generous for a menu and restrictive for anything backed by a real catalogue. Paging is your problem rather than the platform's, so a bot answering from a large dataset needs to decide early what the first fifty are.

Getting Updates: Two Ways, Never Both

The documentation calls them mutually exclusive

There are two ways to receive updates and the documentation describes them as mutually exclusive. Either your server asks Telegram repeatedly for anything new, or Telegram calls your server when something happens. Choosing is an architectural decision made early and it changes what hosting you need.

Setting one silently disables the other

The note is explicit. You will not be able to receive updates by asking for as long as an outgoing delivery address is set up. That is the answer to a very common first day problem where a bot works locally, gets deployed, and then the local copy goes silent. Nothing broke. The other method took over.

The delivery side has published detail

If you go that way, the address must be secure, only four ports are accepted, simultaneous connections run from one to a hundred with a default of forty, and you may set a secret token of up to two hundred and fifty six characters which arrives as a header so you can prove the request came from Telegram. There is also a way to remove the arrangement and optionally drop everything queued.

That last option matters more than it sounds during an incident. If your server has been down and a backlog has built up, switching methods without dropping the queue means the first thing your newly fixed bot does is replay hours of stale requests to people who have moved on. Deciding whether to keep or discard that backlog is a real choice with a visible consequence.

None of this is exotic, but all of it is decided in the first week and lived with for years. That is the honest summary of the whole subject. The platform publishes what it will and will not do, in specific numbers, and the projects that go badly are almost never the ones that read those numbers first. Our notes on automating a channel end to end pick up where this leaves off.

What All of This Adds Up To

A bot is a service desk, not a megaphone

Put the walls in a row and the shape is clear. A bot is excellent at answering people who came to it, at holding a menu, at taking a payment, at running a small tool inside a chat. It is poor at reaching people, constrained in groups, metered in bulk, and restricted in what it may read. Building the first thing is a good idea and building the second is a slow discovery of published limits.

Decide which one you are building first

The cheapest hour you will spend on this is the one before you start, deciding whether the thing you want is a service desk or a megaphone. If it is a desk, a bot is the right tool and the rest of the work is ordinary software. Automating the desk itself is what an auto reply setup and a broadcast bot are for, and both articles run into the same numbers quoted here.

The developer question is the real one

Telegram's own sentence about there being no ready made path for a non-developer is the most useful thing on the whole subject. Either somebody is going to write and host the backend, or you are buying something that already exists. Both are legitimate. Believing there is a third option where a bot does this by itself is where the wasted months come from, and the shortest way past it is having the thing built once, properly.

What to check before committing anybody

Four questions settle it. How many people do you need to reach, and did they come to you or did you find them. How fast does the message have to arrive. Who is running the server at three in the morning. And what happens when the token leaks. If those four have answers, a bot is a reasonable choice, and if they do not, the limits above will answer them for you later at a worse moment. Teams that get this far usually end up with a proper account tool beside the bot rather than instead of it.

Frequently Asked Questions

How do I create a Telegram bot

You message BotFather, choose a name and a username, and receive a token. That takes minutes and costs nothing. The documentation then says you must connect that account to your own backend server through the interface, so the account is the beginning of the work rather than the end.

Can I make a bot without coding

Telegram's own answer is no. The frequently asked questions page states there are no out-of-the-box ways to create a working bot if you are not a developer, and that you will need at least some programming skill. The realistic options are writing it, paying somebody to write it, or using something already built.

How many messages can a bot send

About one per second into a single chat, no more than twenty per minute in a group, and about thirty per second for bulk notifications. Exceeding the first produces an error carrying the number of seconds to wait before retrying.

Can a bot message more than thirty people a second

Yes, by enabling paid broadcasts through BotFather, which raises the ceiling to a thousand messages per second. Every message above the free thirty per second costs a tenth of a star, charged to the bot's own balance.

Can my bot message someone who has not used it

Not reliably. The documentation says a bot may not have access to a user and could be unable to use their identifier unless that user is already known to it by some other means. Holding an identifier is not the same as being able to contact the person behind it.

Why does my bot not see messages in a group

Privacy mode, which is on by default for every bot except one added as an administrator. It can be turned off, but the documentation says the bot must be re-added to the group for the change to take effect, which is why the setting often looks like it did nothing.

Can two of my bots talk to each other

No. Bots cannot see messages from other bots regardless of privacy mode, and the documentation says that was decided deliberately to prevent loops. Any coordination has to happen on your own server before anything is sent.

Can I change my bot username later

No. The documentation says that unlike the name, the username cannot be changed later. It must be five to thirty two characters, Latin letters, digits and underscores only, and must end in the word bot.

What file sizes can a bot handle

Downloads are capped at twenty megabytes. Uploads are capped at ten megabytes for photos and fifty for other files. Download links are valid for at least an hour and then have to be requested again, so store the file identifier rather than the link.

Should I use polling or a webhook

They are documented as mutually exclusive, so it is one or the other. Setting a delivery address stops you receiving updates by asking, which is the usual explanation when a bot goes quiet after deployment. The delivery route needs a secure address, one of four accepted ports, and optionally a secret token sent as a header.