The same product arrives under a queue of names — a forward bot telegram operators pass between themselves, a telegram forwarder bot, a telegram auto forwarder, a telegram bot forward message to group walkthrough with fourteen screenshots — and underneath every one of them sit two API calls and a single question about who is allowed to read the source.
The calls are the easy part. The question is the whole job.
Four of the pieces on this blog end at the same wall, where the Bot API turns out to have no method for the thing being searched for. This one does not. Forwarding is documented, stable and has been shipping for years.
Forwarding is the one job on this beat a bot is genuinely built for
Two methods carry it. forwardMessage moves one message into another chat and hands back the message it sent; forwardMessages takes a list of one to a hundred message identifiers, in strictly increasing order, and returns an identifier for each. Beside them sits copyMessage, which Telegram's own documentation describes as analogous to forwarding except that the copy holds no link back to the original.
Two exclusions are written into the method itself. Service messages and messages with protected content cannot be forwarded, full stop.
It is a better hand than the neighbouring topics get. There is no add-member endpoint on the Bot API at all, and an invite link has no recipient you can aim it at. Here the endpoint is real, the parameters are public, and nothing has to be reverse-engineered from a vendor's screenshots.
Why can't a telegram forward bot see the channel it is meant to mirror?
Because it is not in the channel.
Telegram's Bot FAQ states the rule in one clause: a bot receives all messages from channels where it is a member. Nothing arrives from anywhere else. No token scope widens it, no parameter overrides it, and the person who decides whether your bot is in that channel is the person who runs the channel.
Groups add a second gate on top. Bots joining a group run in privacy mode by default, which limits them to commands aimed at them and a narrow slice of everything else. Telegram documents one exception, and it is the one that matters here: a bot added to a group as an administrator always receives all messages. The other route runs through BotFather, where privacy mode can be switched off before the bot joins.
Put those two rules together and the popular use case falls apart in public. Almost everybody searching for a forwarding bot wants to mirror a channel somebody else runs, usually a signals channel, a deals channel or a news feed. That is precisely the case a bot cannot serve, because serving it requires the other channel's owner to hand your bot an admin badge, and they have no reason to.
One documented side door is worth knowing about, and it is not a trick. A channel can have a discussion group attached to it, and Telegram itself forwards every post in that channel into the group. The Bot API marks those arrivals with is_automatic_forward, a field that exists precisely so your code can tell an auto-forwarded channel post apart from something a person typed. A bot sitting in an open discussion group therefore sees the channel's posts without ever being added to the channel.
It is narrow. The owner has to have linked a discussion group, left it open to join and not restricted bots inside it, and what you are reading is a mirror of the posts rather than the channel itself. Still, it is the one legitimate route from a channel you do not run to a bot you do, and none of the forwarding vendors mention it.
The same wall stands on the recipient side. A bot cannot open a conversation with a person who has never written to it, so forwarding a post out to a list of users only ever reaches the ones who pressed Start. It is the constraint underneath how a mass DM run is paced across the pool, and it applies to forwards exactly as it applies to fresh text.
So the honest split is this. Chats your team administers are bot territory, and you should stay there, because a bot costs nothing, needs no phone number and cannot be spam-restricted the way an account can. Everything the team does not administer is account territory, with every cost that implies. Most of the disappointment in this category comes from people who assumed the first case and were quoted software built for the second.
Forward or copy: the line that says where a post came from
A forward carries provenance. The message arrives with its origin attached, which is what draws the forwarded-from line at the top of the bubble, and that line is the entire difference between the two methods. A copy carries nothing: copyMessage produces a message with no link to the original, so it reads as something you wrote.
On the account side the same switch exists as a flag on messages.forwardMessages that forwards without quoting the original author, sitting next to flags for stripping media captions, sending silently and scheduling for later.
There is a reader-side setting too. A user who restricts Forwarded Messages in their privacy settings no longer has forwards of their messages link back to their profile; their display name appears as plain unlinked text instead.
Most tools sold as forwarders are copiers. That is worth saying out loud, because the two words are used interchangeably in this market and they describe opposite behaviours toward the person whose post is being moved.
How fast can a bot forward before Telegram slows it down?
Slower than most people assume, and the numbers are published. Telegram asks for no more than one message per second in a single chat, caps a bot at twenty messages per minute inside a group, and puts the overall broadcast rate at roughly thirty messages per second. Go past one of those and the API returns 429 alongside a retry_after value counting the seconds left before the request can be repeated.
Accounts get no such courtesy. They collect FLOOD_WAIT_X instead, and then PEER_FLOOD if the behaviour keeps looking like bulk outreach, which is the same escalation described in the two different 200s behind an add. Everything else you will read about daily forwarding ceilings is somebody's observation of their own accounts, ours included, and none of it is policy.
Four ways a telegram auto forwarder gets built, and what each one can reach
Strip the branding away and there are four approaches, not forty. They differ on reach, on attribution and on what breaks first.
| Approach | What it reaches | Source stays visible | What stops it first |
|---|---|---|---|
| Bot API forward | Chats the bot already sits in | Yes | Not being in the source |
| Bot API copy | The same chats, nothing more | No | Service and invoice messages |
| User session over MTProto | Anything the account can open | Your choice | Flood waits, then spam reports |
| By hand, in the app | Anything you can open | Yes | You |
Rows one and two are the same product with one parameter changed, which is why a hosted panel can offer both for the same price. Row four is not a joke: for a handful of posts a day between two channels you administer, a person with a phone beats every automation on this page and costs nothing.
Batching is the quiet advantage the bot rows have. Because forwardMessages accepts up to a hundred identifiers in a single call, a backlog moves in a handful of requests instead of a hundred, and the per-chat pacing applies to the call rather than to each message inside it. An account working through a list of separate posts gets no such shortcut, which is why a first sync of an old channel is the slowest thing a session pool ever does.
Row three is where our software lives. A logged-in account sees what a person sees, so it can read a public channel it joined and repost out of it, and the Group Message Blaster does exactly that in forward mode across a pool of accounts, scheduled or looped, though pushing one post into many rooms hits walls a single mirror never meets. The screen below belongs to the Mass DM module, where the same choice appears as Repost mode next to the delay fields.
Reach is the only thing row three buys, and it is expensive. Every account needs a number, a proxy and warmup time before it forwards anything, which is why the first question we ask is whether the source is a chat you already control. If it is, the Bot API is free and you should use it. If it is not, the machinery in the six module groups on the overview page is what closes the gap, and the same accounts that forward are the accounts that scrape, join and message — the two different things sold as a scraper run on that identical pool.
Whatever the row, something has to be awake for a new post to be noticed at all. A bot subscribes to an update stream and reacts; an account has to hold an open connection, which means a machine that stays on. The word "auto" hides exactly that in every product name in this category, and it turns a month-long mirror into an infrastructure question rather than a scripting one.
Filtering is the other thing to settle before anything is wired together. Telegram forwards a message or refuses to; it offers no keyword rules, no media-type rules and no find-and-replace along the way. Every filter you have seen advertised is implemented on the tool's side, after the post arrives and before it goes back out, so a mirror is only ever as accurate as the code sitting between the two chats.
Cost separates the rows further. Hosted forwarding panels bill per channel pair or per message, so a mirror running all month grows a bill that tracks volume, while a desktop licence does not; what the licence costs against a per-message fee is the comparison worth running before either.
What will a forwarding setup not do for you?
It will not open a source that has been closed. When a channel enables Restrict saving content, the chat carries a flag the Bot API exposes as has_protected_content, and messages from that chat cannot be forwarded elsewhere. Both methods refuse, copy included, because the toggle stops the content leaving rather than merely hiding its author. On the account side the refusal is named: CHAT_FORWARDS_RESTRICTED, described as not being able to forward messages from a protected chat.
Our software does not change any of that. There is no field in it that unsets another channel's flag, no setting that raises Telegram's rate ceilings, and no accounts or proxies in the box — you bring those. What it does is run many sessions through one pacing engine with one log, so a wait collected in one place is visible everywhere.
Every quotation above was checked against Telegram's own pages in August 2026, and those pages move. Methods gain parameters, the FAQ gets reworded, and a forwarding setup built from a two-year-old tutorial will be wrong about something, so read the method page before trusting anybody's summary of it — this one included.
Then there is the part almost nobody in this category writes down. Telegram's Terms of Service ask you not to use the service to send spam, and a mirror pushing a stranger's posts into unrelated groups is closer to that line than a team syndicating its own announcements. Volume is not a defence there, in the same way that why a report count is not a lever holds on the moderation side.
The harder question sits outside Telegram entirely. The posts you mirror belong to whoever wrote them, and republishing another channel wholesale is an attribution problem between you and that author that no API flag resolves. Copy mode makes it worse by stripping out the only credit the platform hands over for free. Nothing in the documentation will stop you, no error string fires, and the complaint arrives from a person rather than from an endpoint. That is the failure we have watched end more mirrors than any rate limit, and it is the one thing nobody selling forwarding tools writes down.
If you are unsure which side of the membership line your case falls on, send us the source and destination and we will say which one it needs. The rest of the notes on this beat take the neighbouring modules apart the same way.