Your Telegram Bot Is a String of Characters, and Three Rules Decide What It Can Do

Two search phrases sit right next to each other whenever anyone looks this up: the token, and the chat id. That pairing is the whole beginner problem in miniature. People get the first one in a minute and then discover the bot has nowhere to speak.

So this is not a framework comparison. It is what the token is, what stops the bot once you have it, and the three published limits that decide the shape of anything you build.

What BotFather actually gives you

Open a chat with Telegram's own bot for creating bots, send /newbot, answer two questions. Telegram's documentation describes the exchange exactly: it asks for a name and a username, then generates an authentication token.

That token is the bot. It is a string with a numeric prefix and a long secret after a colon, and Telegram's own words for it are that it authorises the bot and is required to send requests to the API. There is no separate password, no account to log into, no second credential. Anyone holding the string controls the bot completely, which is why it belongs in an environment variable and never in a repository, a screenshot or a group chat.

At that moment you have a working bot that does nothing, because nothing is listening. That is the correct state to be in and it is where the actual work starts.

Rule one: in a group, your bot is deliberately deaf

This is the single most common "my bot is broken" report, and it is documented behaviour rather than a bug. Telegram states that by default, all bots added to groups run in privacy mode and only see relevant messages and commands.

So a bot sitting in a group does not receive ordinary conversation. It receives messages that address it and commands, and that is the design. If you are building a moderation bot that needs to read everything, you change that setting through BotFather deliberately. If you are building a helper that answers questions, leave it alone: the default is the privacy-preserving one and it also spares you an enormous volume of irrelevant updates.

A related rule that catches people building bot-to-bot workflows: Telegram decided bots will not see messages from other bots at all, regardless of mode, specifically to stop them getting stuck in loops. Two of your own bots cannot talk to each other directly.

Rule two: one message per second, per chat

Telegram's guidance is direct. In a single chat, avoid sending more than one message per second. It phrases it as advice rather than a hard wall, which in practice means the limit is enforced by making your bot wait rather than by refusing outright.

The design consequence is worth absorbing early: a bot that answers a question in six short messages is six times slower to that user than one that answers in a single message, and it feels it. Compose one reply rather than narrating.

Rule three: thirty a second, in bulk, and the arithmetic that follows

For bulk notifications, Telegram states that bots are not able to broadcast more than about thirty messages per second.

Do the arithmetic before you design a broadcast feature, because it is unforgiving. Ten thousand subscribers at thirty a second is a shade over five and a half minutes of continuous sending, assuming nothing fails and nothing retries. A hundred thousand is nearly an hour. Any bot whose purpose is announcing something to a large list is really a queue with a bot on the end of it, and building it as a simple loop will produce a broadcast that is still going out long after the news is stale.

The practical answers are the ordinary ones: send to a channel and let subscribers pull, rather than pushing to every user individually; or accept the queue and show progress. Choose deliberately, at the start.

A first version that is small on purpose

Telegram asks all developers to support a small set of basic commands, and puts /start at the top of the list as the one that begins the interaction with a user. It also asks that you respond to all messages sent to your bot. Between those two lines you have a specification for a first version.

• Answer /start with a short statement of what the bot does. It is the first thing every user sees and it is the one screen you can count on.
• Match a handful of real repeat questions, taken from the messages you are already answering by hand rather than from a guessed list.
• Never go silent. Unrecognised input should get a human-will-follow-up reply, because a bot that says nothing reads as broken and a bot that says "I did not understand that, someone will get back to you" reads as working.

Get that loop reliable and everything after it, scheduled posts, group moderation, a database lookup, is an addition rather than a rebuild.

Two things you cannot buy, and one you can

A note on what this marketplace does and does not have, since it is the obvious question on a site like this one.

There is no bot to buy. Searching all 16,735 live listings for the word in a title returns three results, and all three are something else: a console game with "Bot" in the name, a Telegram listing where a bot is the delivery mechanism, and a Facebook listing where the seller hands over admin rights through one. Nobody sells bots here, because the token is free and takes a minute.

What you may want is an ordinary Telegram account to test against, so that you are not adding your personal number to a bot you are still debugging, and a number to register it with. Both exist: Telegram accounts and SMS verification numbers. Warranty on the account shelf runs twelve hours at the median, so test the login the moment it arrives rather than at the weekend.

One asymmetry worth knowing if you are building something public-facing: Telegram's verification applies to channels, bots and public groups. Your bot is on the eligible list. The account you run it from is not.

The reference to keep open while you build is Telegram's own Bot API documentation. Everything quoted on this page is from it, and it is the only source that stays current.