How to Add a Bot to a Telegram Group and Make It Hear You

You add a bot to your group, the member count goes up by one, and then nothing happens. No greeting, no response to the command you just typed, no sign it noticed anything at all. Most people conclude the bot is broken.

It is almost never broken. Telegram deliberately makes a newly added bot deaf to ordinary messages, and the setting that does this is on by default. Turning it off has a second step nobody mentions, adding the bot as an admin instead skips the problem entirely, and in a channel the whole question does not apply, because a bot there can only be an admin.

Here is what actually happens when a bot enters a room, in the order you meet it.

What Adding a Bot Actually Does

Putting a bot in a group is not a configuration step. It is one of only two events in the entire platform that give a bot permission to speak to you at all.

A bot cannot let itself in

Telegram's own wording is blunt about this. A bot cannot start a conversation with anyone; a user has to either message it first or add it to a group. There is no invitation a bot can accept and no link it can follow. That is not a limitation of the software, it is a rule the platform enforces on every bot equally.

That single rule is why the whole ecosystem works the way it does. Every bot you have ever used got its opening because a person deliberately gave it one, and the group you are about to add one to is exactly that kind of opening.

The add is a permission, not a setting

When you add a bot, you are handing it standing access to a room full of people who did not individually agree to anything. Telegram softens that by restricting what the bot can see, which is the source of all the confusion later. The restriction is the apology, and like most apologies it is easy to miss until something goes wrong.

Understanding it as a permission rather than an installation changes how you think about the rest. The bot is not being configured, it is being admitted, and everything after that is about how much of the room it is allowed to hear.

Anyone in the room can usually do it

In most groups any member can add a bot, which is worth sitting with for a moment. If your group has a hundred people in it, a hundred people can introduce software into it. The setting that restricts adding members restricts adding bots along with them, and turning it on is the only thing standing between your room and somebody's weekend project.

The same is true of the bot leaving. Any admin can remove it, and in a room with several admins the bot can disappear without the person who set it up hearing about it. If something depends on that bot running, the room's admin list is part of the dependency whether you like it or not.

The Three Ways to Put a Bot in a Room

They look interchangeable and they are not. Two of them produce a bot that hears almost nothing, and one produces a bot that hears everything.

Through the group's member list

Open the group, add member, search the bot's username, confirm. This is the path most people take and it produces an ordinary member with the default restrictions in place. Nothing warns you that a quieter version of the bot is what you just installed.

There is one detail worth noticing here. The search only finds the bot if you have its exact username, since bots do not appear in the ordinary contact suggestions. Getting that username from a trustworthy place matters, because impersonating a popular bot with a near identical name is an old and effective trick.

Through the bot's own profile

Open the bot's chat or profile and choose the option to add it to a group, then pick the room. The result is identical to the first path, but the interface sometimes offers to grant admin rights at the same moment, which quietly changes everything.

This is the safer route for exactly that reason. You are working from the bot's own page rather than from a name you typed, so you know which bot you are dealing with. For anything that will hold rights in a room that matters, start from the bot.

By promoting it after the fact

You can add the bot normally and promote it to admin later. This is the path that leaves people confused, because promoting an existing bot does not always produce the same behaviour as adding it as an admin in the first place. The difference is not cosmetic and it is covered further down.

Promotion also has a practical advantage. You can watch the bot behave as an ordinary member first, see what it does, and only then decide whether it deserves more. A bot that misbehaves at member level is not going to improve with rights.

Why Your Bot Sits There Doing Nothing

This is the question that brought most people here, and it has one answer.

Privacy mode is on by default

Every bot added to a group arrives with privacy mode enabled unless it was added as an administrator. In that state the bot does not receive ordinary messages. People type, the conversation flows, and the bot genuinely never sees any of it. From the bot's side the room is almost silent, which is exactly what its developer intended.

Nothing about the interface tells you this. The bot appears in the member list like anybody else, and its silence looks like a fault rather than a rule.

It is a Telegram rule, not a bug in the bot

The restriction lives on Telegram's side, not in the bot's code. The developer cannot work around it from their end, and no amount of restarting the bot changes what the platform is willing to forward. Asking them to fix it is asking them to change something they do not control.

This matters when you are deciding who to blame. A bot that works perfectly in a private chat and does nothing in a group is behaving exactly as designed, and the fix is a setting rather than a support ticket.

The exception that confuses everyone

A bot added as an administrator does not get privacy mode at all. It hears the room from the first second. This is why one person's identical setup works and another's does not, and why the advice you find online contradicts itself depending on which way the writer happened to add theirs.

It also explains why so many setup guides are wrong without being dishonest. The writer added their bot one way, it worked, and they wrote down what they did. Whether that advice works for you depends entirely on a step most guides never thought to mention.

It is also the reason this article exists in the shape it does. Two people can follow the same six steps, get different results, and both be doing it correctly. Once you know that admission carries the setting, the contradictory advice stops being contradictory and becomes a question about how the bot got in. That question has an answer you can check in about ten seconds.

What a Bot With Privacy On Can See

Privacy mode is not a blindfold. The list of what still reaches the bot is specific and short, and knowing it is usually enough to work with.

Commands aimed at it

A command addressed directly to the bot always arrives, including the form where the bot's username is attached to the command itself. That form is the reliable one in a room with several bots, since it removes any question about who was being spoken to. Our guide on how bot commands are structured covers the syntax properly.

In practice this is the first thing to try when a bot seems dead. Type its command with the username attached and see whether anything comes back. A response means the bot is alive and privacy mode is simply doing its job, which is a completely different problem from a bot that is not running.

General commands, but only sometimes

A plain command with no username attached reaches the bot only if it was the last bot to send a message in that group. This is the single strangest rule in the whole system and it explains a genuinely maddening symptom, where the same command works and then stops working depending on what happened in the room five minutes earlier.

In a room with one bot you will never notice. In a room with three, the behaviour looks random until you know the rule, and then it looks obvious. Anyone running several bots learns to attach the username by reflex, usually after losing an afternoon to this.

Replies and service messages

Replies to the bot's own messages reach it, which is how conversational flows survive privacy mode at all. Messages sent through the bot's inline mode reach it too. And service messages, the automatic lines about people joining, leaving, being promoted or having the title changed, arrive regardless of the setting.

That last part is more useful than it sounds. A welcome bot, a logger, or anything that reacts to membership changes can work perfectly well with privacy mode left on, because the events it cares about were never filtered in the first place.

What it never sees

Ordinary conversation. Photos, links, files, arguments, everything people actually say to each other. It also never sees messages sent by other bots, and that rule holds whether privacy mode is on or off, which quietly rules out an entire category of bot-to-bot designs people try to build.

The bot-to-bot rule catches people building chains, where one bot is supposed to react to another's output. It does not work and no setting makes it work. Anything of that shape has to be joined up behind the scenes, between the services themselves, rather than through the room.

There is a design lesson buried in that rule. Telegram treats a group as a place for people, and bots as guests who are told only what concerns them. Every restriction described here follows from that one decision, which is why arguing with any single restriction rarely gets anywhere. The platform is not being awkward, it is being consistent.

Turning Privacy Off, and the Step Everyone Misses

If the bot genuinely needs to read the room, the setting can be switched. There is a second step, and skipping it is why so many people conclude the switch did not work.

The setting lives with the bot's owner

Privacy mode belongs to the bot, not to your group. It is changed by whoever controls the bot through the same account that created it, using the dedicated command for it. If you did not build the bot, you cannot change this yourself and you have to ask.

This is a good moment to notice how much of a group's behaviour sits with somebody outside it. The person who owns the bot decides what it can hear, what it does with what it hears, and whether it keeps running at all. Our guide on creating a bot of your own is the answer when that dependency is not acceptable.

The bot must be re-added afterwards

This is the step that gets missed. Telegram states plainly that after changing the setting, the bot has to be re-added to the group for it to take effect. Removing it and adding it back is not a superstition here, it is the documented requirement.

Everyone who tells you they flipped the setting and nothing changed skipped this. The bot in your room is still running under the rules it was admitted with, because the rules are attached to the membership rather than to the bot's current configuration.

This is worth a slightly bigger warning than it usually gets. If the group is already busy, removing and adding a bot produces two service lines everyone sees, and in a client's room that looks like somebody fiddling. Doing it early, before the room fills up, avoids the audience entirely. It is a small thing that separates a setup somebody planned from one somebody repaired.

Do it only when you have to

Telegram's own guidance is that privacy mode should stay on unless the bot cannot function without reading everything, and that recommendation is not decoration. A bot with privacy off receives every message in the room, which means the person running it receives every message in the room. If it belongs to somebody outside your organisation, that is worth a conversation before you flip anything.

There is also a practical cost. A bot receiving every message in a busy room is handling far more traffic than one receiving only its commands, and bots that fall over under load usually do it in rooms where somebody turned this off for convenience rather than necessity.

Adding the Bot as an Admin Instead

For a lot of bots this is simply the correct path, and it sidesteps the entire privacy question.

Admin bots hear everything

An administrator bot receives all messages, full stop. There is no filtering, no last-bot-to-speak rule, and no re-adding ritual. If the bot needs to moderate, log, translate or respond to ordinary conversation, this is what it needs.

This is why moderation bots ask for admin immediately. It is not empire building, it is the only configuration in which they can see the messages they are supposed to be moderating. A moderation bot without admin rights is decorative.

Added as admin versus promoted later

The documented exception is about bots that were added to a group as admins, which is a slightly different act from adding a bot and promoting it afterwards. If a promoted bot still behaves as though it cannot hear the room, remove it and add it again with the rights granted at the moment of admission. That sequence resolves it.

The remove and re-add sequence is worth knowing as a general troubleshooting move. It resets the terms the bot was admitted under, and a surprising share of unexplained bot behaviour in groups comes down to a bot still running under conditions that were changed months ago.

Admin is not a small thing to hand out

Making a bot an administrator gives a piece of software the ability to act on your members. Depending on the rights you tick it can delete messages, restrict people, and change what the room is. Our breakdown of what each admin right actually permits is worth reading before you tick anything, because the list is longer and more specific than the interface suggests.

The uncomfortable version of this is that you are trusting the person behind the bot, not the bot. Software does what its operator ships, and today's harmless utility is one update away from something else. That is not paranoia, it is simply what handing out rights means.

A reasonable rule of thumb is to ask what the worst version of this bot could do with the rights you are about to grant. Not the version you were shown, the version that exists after an update you never see. If that answer is uncomfortable, grant less and find out whether the bot still does its job. Most of the time it does, and when it does not you have learned something specific.

Which Admin Rights a Bot Actually Needs

The temptation is to grant everything so it works. The better habit is to grant the two or three rights the bot's job requires.

Start from the job

A moderation bot needs to delete messages and restrict members. A welcome bot needs almost nothing. A bot that posts scheduled content needs to send messages and nothing else. Writing down the job first turns a vague permission screen into a short list. It also gives you something to check against later, when somebody asks why the bot can do what it does.

Writing it down also makes the conversation with the bot's developer much shorter. Instead of asking what rights it needs and receiving the maximal answer, you can ask why it needs a specific one. The answers to that question are informative in both directions.

The rights that carry real weight

Deleting messages, banning members and inviting people are the three that change what happens to humans. Everything else is closer to housekeeping. If a bot asks for those three and its stated purpose is posting a daily message, that mismatch is the whole story.

Inviting is the one people underestimate. A bot that can invite can grow your room with people you did not choose, and unlike a message that can be deleted, a membership is a thing you then have to undo one person at a time.

Rights are permanent until reviewed

Nobody schedules a permission review. A bot added for a two week experiment holds its rights a year later, long after the person who added it has left. Groups accumulate this the same way they accumulate admins, and the fix is a calendar entry rather than a clever tool. A quarterly look at the member list costs ten minutes and catches nearly all of it.

A reasonable habit is to review bots whenever you review admins, since both are the same category of decision. If your group has never had either review, the bots are usually the easier place to start, because nobody's feelings are involved.

Bots in Channels Are a Different Rule

Everything above concerns groups. In a channel the situation is simpler and considerably stricter.

A bot in a channel can only be an admin

Telegram refuses outright to add a bot to a channel as an ordinary member, and the platform's own error text says exactly that. There is no member-level bot in a channel, so the question of how to add one without admin rights has a one word answer.

Every search result promising a way around this is describing something else, usually a discussion group attached to the channel, which is a group and follows group rules.

The practical version of this is short. Decide before you start whether the thing you are building is a channel or a group, because the bot rules follow from that choice and not the other way round. Trying to make a channel behave like a group by adding software to it is a well travelled dead end, and the platform will keep refusing in ways that look like different problems each time.

Why the rule exists

A channel is a broadcast surface with no ordinary participants, so member level does not mean anything there. The only meaningful presence is the ability to post and manage, and that is what admin status is.

It also means the question people search for has no configuration answer. There is nothing to enable and no permission to reduce. A bot in a channel is an administrator or it is not there, and everything written to the contrary is describing a group.

The discussion group is the loophole people actually want

If you want a bot reading and answering conversation around a channel, that conversation lives in the attached discussion group, and there the bot is an ordinary group member with all the privacy rules described above. Our piece on running a broadcast bot covers the posting side of this arrangement.

This arrangement is more common than people realise. A channel broadcasts, the attached group carries the conversation, and the bot lives where the conversation is. Once you see it that way, the two sets of rules stop feeling contradictory.

When Telegram Refuses to Add the Bot

Sometimes the add simply fails. The refusals are specific and each one means something different.

The bot's owner blocked group joining

Bots can be configured so they cannot be added to groups at all, and when that is the case Telegram refuses the add with a message saying precisely that. This is a decision made by whoever built the bot, usually for bots meant to be used only in private chats. Nothing on your side will change it.

It is also a useful signal about what the bot is for. A bot that refuses to enter groups was built for private use, and pushing it into a room it was not designed for would produce odd behaviour even if the platform allowed it.

The room already has too many bots

There is a ceiling on bots per chat and the platform refuses once you reach it. Groups that have been running for years hit this, usually while carrying several bots nobody remembers adding and none of which still work.

Clearing them out is easy and slightly awkward, because nobody remembers what half of them did. The safe order is to remove the ones nobody can name, wait a week, and see whether anything stops working. Almost nothing ever does.

You are not allowed to add members

If the group restricts who can add members, adding a bot is refused for the same reason adding a person would be. The message names admin rights rather than bots, which sends people looking for a bot specific problem that does not exist.

If you are an admin and still cannot add the bot, check whether your own admin role actually carries the right to add members. Admin is not one thing, and a role created for deleting spam may not include it.

How Many Bots One Room Can Hold

The ceiling matters less than what happens well before you reach it.

There is a hard limit

Telegram enforces a maximum number of bots per chat and returns a specific refusal when you exceed it. Most rooms never approach it, and the ones that do are usually carrying accumulated experiments rather than a genuine need. The ceiling is a symptom rather than a constraint, in other words.

The number is enforced by Telegram rather than by anything in your settings, so there is nothing to raise. When you hit it, the only path forward is removing something already there.

The practical limit is much lower

Two or three active bots in one room is already enough to produce collisions. The last-bot-to-speak rule for general commands means bots interfere with each other's command handling, and the more of them there are, the more often a command lands in the wrong place.

Attaching the username to commands removes the ambiguity, but it also means telling every member of your group to type something longer than they want to type. Fewer bots is the cleaner answer.

Dead bots are not harmless

A bot whose service stopped running still sits in your member list holding whatever rights it was given. If that service is later sold, revived by somebody else, or has its access token leaked, the rights are still there waiting. Removing bots you stopped using is basic hygiene and almost nobody does it. Our note on what a bot token really is explains why a leaked one matters so much.

There is also a quieter cost. A member list full of software makes a room look unattended, and people notice. A group with four bots and eleven humans reads as abandoned even when it is not.

Why Your Bot Cannot See Who Joined

A separate class of confusion, with a separate cause. This one is not about privacy mode.

Membership updates need admin plus a request

To receive updates about other members joining or leaving, a bot has to be an administrator in the chat and its developer has to explicitly ask for that update type. Both conditions, not either. A bot that is admin but never asked receives nothing.

This is the single most common cause of a welcome bot that greets nobody. The bot is in the room, it is even an admin, and it was never asking for the thing it needs. That is a change on the developer's side and no amount of group configuration reaches it.

There is a diagnostic worth knowing here. If a bot greets people sometimes and ignores them other times, that is usually the difference between the automatic service line and the structured update, arriving under different conditions. If it greets nobody at all, the bot is either not an admin or never asked for the update. Neither of those is fixed by removing and adding it again, which is what most people try first.

Which is why welcome bots fail oddly

Service messages about people joining are visible to every bot regardless of privacy mode, but the structured membership update is the one carrying detail worth acting on. Bots built against the first work everywhere and know little. Bots built against the second know a lot and need to be admins.

The symptom is distinctive once you know it. The bot reacts to some arrivals and not others, or it reacts but knows nothing about who arrived. Both of those point at the same gap rather than at anything you did wrong.

Counting members is a different call again

Reading how many people are in a room, or checking one person's status, are separate operations with their own requirements. A bot can often count without being an admin while being unable to watch changes as they happen, which is why some tools show you a total that never updates.

This is worth checking before you trust a number a bot shows you. A count that was correct when the bot last asked is not the same thing as a count that is correct now, and dashboards rarely tell you which one you are looking at.

What the Bot Learns About Itself

There is one update a bot always gets, and it is the one worth building on.

The bot is told when its own status changes

When a bot is added, removed, promoted or demoted, it receives an update about its own membership. It knows the moment it entered your room and it knows who put it there. That is more context than it gets about almost anything else that happens afterwards.

Well built bots use this as their trigger. The greeting you see the instant a good bot joins is that update being handled, and a bot that says nothing on arrival is usually one that never listened for it.

It also learns when you block it

In a private chat the same update fires when somebody blocks or unblocks the bot. That is the only signal of its kind, and it is how a bot can stop wasting attempts on people who have shut the door.

Bots that ignore this signal keep sending into a closed door and burn their sending allowance on people who will never see anything. Bots that handle it stop, which is both more polite and cheaper to run.

Use it as the setup check

If you are testing whether a bot is correctly installed, adding it and watching for a reaction tells you more than typing commands does. A bot that greets you on arrival has working update delivery. A silent one might be fine and might be dead, and you cannot tell them apart from the member list.

The same trick works for diagnosing a bot that used to work. Remove it, add it again, and watch. If nothing happens on arrival, the problem is on the bot's side and no setting in your group is going to fix it.

How the Bot Receives Anything at All

Underneath the setting screens, there are two ways a bot hears from Telegram, and the choice affects what you experience as reliability.

Asking repeatedly, or being called

A bot either polls Telegram for new updates or has them pushed to an address it owns. The first needs nothing but a running process. The second needs a reachable server with a valid certificate on one of a small set of permitted ports. Our write up on setting up a webhook goes through the specifics.

For most people this is somebody else's decision. It matters here only because the two fail in different ways, and knowing which one your bot uses tells you what question to ask when it goes quiet.

Why this shows up as flakiness

A polling bot that stops being run stops responding instantly and silently. A pushed bot whose certificate expired does the same. In both cases the bot is still in your group with all its rights, still visible in the member list, and completely inert. The room gives you no way to tell.

What to check before blaming the group

If a bot worked yesterday and does nothing today, the group settings are the least likely cause, because nothing in the room changed. Check whether the service is running before you start removing and re-adding things. Half the re-adding rituals people perform are treatments for a problem in a different building. Our bot manager exists partly because knowing which of your bots is actually alive should not require guessing.

Removing a Bot and What Survives

Taking a bot out is simple. What it leaves behind is less obvious.

Removal is immediate

Remove the bot from the member list and it stops receiving anything from that room at once. There is no cooling off period and no cached access.

One thing removal does not do is take back what the bot posted. Its messages stay in the history like anybody else's, and clearing those is a separate job with its own admin rights attached.

What it already collected stays collected

Anything the bot received while it was in the room is on somebody else's server and removal does not reach back. If the bot was running with privacy off, that includes the conversation. This is the part worth thinking about before you add a bot rather than after you remove one.

Re-adding starts a fresh negotiation

A bot added back arrives under whatever its current settings are, not the ones it had before. That is exactly why re-adding fixes the privacy problem, and it is also why a bot you removed for misbehaving can come back with different capabilities than the ones it left with.

It is worth being deliberate about this rather than treating re-adding as a reset button. Check what the bot's settings are now, not what they were when you first trusted it, because the version arriving is the current one.

What Operators Get Wrong About Bots in Groups

Everything above is mechanics. This is the part where the mechanics meet decisions people make badly.

Granting admin to skip a problem you have not diagnosed

The fastest way to make a bot work is to make it an admin, which is why people do it before understanding why it was silent. The bot starts working, the room now contains software that hears everything and can act on members, and nobody revisits it. Diagnose first, then grant the least that solves it.

Treating a bot as a member-adding shortcut

A frequent hope is that a bot in the group can pull people into it. Bots operate under the same restrictions everyone else does, including the privacy settings of the person being added, and being an admin does not repeal those. This is the query that brings a lot of people to this page and the honest answer is that the bot is not the tool for it. Building a room's membership deliberately is what our member adder is for, and it works within the same rules rather than pretending they are not there.

Adding somebody else's bot to a client's room

Agencies do this constantly. A third party bot goes into a client's group, hears everything if it was made admin, and the agency has quietly introduced a data relationship nobody signed off. If you run rooms on behalf of other people, knowing which bot sits in which room matters as much as knowing which account does, which is the sort of record our account manager keeps. When the requirement is genuinely specific, a bot you control is better than one you borrowed, and that is usually where a custom build starts.

Assuming the bot is the interesting part

A bot is plumbing. It does not create demand, it does not make a quiet room busy, and it will not rescue a group nobody wanted to join. Rooms that work have a reason to exist first and automation second, and the ones that fail almost always got that order backwards. Our guide on what an auto reply bot is genuinely good for is a realistic starting point.

Frequently Asked Questions

How do I add a bot to a Telegram group?

Open the group, choose to add a member, search for the bot's username and confirm. You can also do it from the bot's own profile, which sometimes offers to grant admin rights at the same time. In most groups any member can do this.

Why does my bot not respond in the group?

Privacy mode is on by default, so the bot never receives ordinary messages. Send it a command addressed directly to it, or add it as an administrator, which removes the restriction entirely. The bot itself is almost certainly fine.

What is privacy mode for Telegram bots?

A default restriction that limits a group bot to commands aimed at it, replies to its own messages, messages sent through it, and service messages. Everything else in the conversation is hidden from it by Telegram rather than by the bot's own code.

How do I turn off privacy mode?

The bot's owner changes it through the account that created the bot. Afterwards the bot must be removed from the group and added again, otherwise the change does not take effect there. If you did not build the bot, you have to ask whoever did.

Can I add a bot to a Telegram channel without admin rights?

No. Telegram only allows bots in channels as administrators and refuses any other kind of add. If you want a bot reading conversation, that belongs in the channel's discussion group, which follows ordinary group rules.

Can a bot add members to my group?

Only within the same limits that apply to people, including the privacy settings of whoever is being added. Administrator rights do not override those settings, so a bot is not a way around them.

How many bots can be in one Telegram group?

There is a hard ceiling and Telegram refuses further additions once you reach it. The practical limit is much lower, since several active bots interfere with each other's handling of plain commands.

Why can I not add this bot to my group?

Either the bot's owner disabled group joining, the room already holds too many bots, or the group restricts who may add members. The refusal message differs in each case and tells you which one you hit.

Does my bot see who joins and leaves?

It sees the automatic service messages either way. To receive structured membership updates it must be an administrator and its developer must explicitly request that update type, which is why some welcome bots work only partially.

Does removing a bot delete what it collected?

No. Removal stops it receiving anything new from that moment, but whatever it already received is stored elsewhere and is unaffected. That is worth considering before adding a bot rather than after removing one.