Telegram Auto Forward: 4 Ways to Mirror a Channel

Someone posts in a channel, and you want that post to appear somewhere else within seconds. That is the whole job. It sounds like it should take five minutes to set up, and for one message it does: hold the message, tap forward, pick a chat. The trouble starts at the second word in the sentence, the word auto, because the moment nobody is holding the phone the job stops being about forwarding and starts being about permissions, rate limits, attribution and what happens when the original post gets edited at two in the morning.

This guide covers four ways to do it, from the built-in tools to a mirror that runs unattended, and it is specific about what each one cannot do. Everything about how Telegram behaves comes from Telegram's own documentation, quoted where it matters: the Bot API reference, the protocol method definitions, the FAQ and the release post that introduced content protection. Where a number is ours rather than Telegram's, the text says so.

One thing worth settling before the methods: this is not a guide about stealing channels. Copying somebody else's posts word for word into your own channel is a business decision with consequences, and there is a section near the end about where the takedown path actually leads. Most people asking about auto forward are not doing that anyway. They are mirroring their own channel into a group, moving posts between their own two channels, feeding a team inbox, or building a filtered feed from sources they already read.

What "auto forward" actually means

Three different jobs hide behind the same phrase, and they need different tools. Picking the wrong one is why people end up with a script that works for a week and then quietly stops.

One-off forwarding

You have a batch of messages and you want them somewhere else, once. Backing up a channel before you delete it, moving an archive into a new home, seeding a fresh group with the best of an old one. This runs once and finishes, so rate limits and long-term sync do not matter much. What matters is completeness and order.

Continuous mirroring

Whatever appears in A should appear in B, from now on, forever. This is the one most people actually want and it is the one with real engineering behind it: something has to be listening at all times, it has to survive restarts, it has to handle the source going quiet for three days and then posting forty messages in a minute.

Filtered relay

Mirroring, but only some of it. Only posts containing a keyword, only photos, only messages from one specific author in a group, everything except the ads. The relay is doing editorial work, which means it needs to read the content before deciding, and it means every decision it gets wrong is visible to your audience.

The four methods below can all do the first job. Two of them do the second properly. Only the last two do the third without a lot of extra work.

Forward or copy: the decision that changes everything

Before any tool, one choice: does the destination message keep a visible link back to where it came from, or does it arrive looking like your own post? Telegram treats these as two different operations, and almost every frustration people have with forwarding bots traces back to not having made this choice deliberately.

A forward carries its origin with it

A forwarded message keeps a header naming the source and, for public sources, linking to it. In the Bot API this shows up as the forward_origin field, described as "Information about the original message for forwarded messages", and it comes in four flavours depending on where the message came from: a known user, a hidden user, a chat, or a channel. That header is not cosmetic. It is the difference between "here is something interesting I found" and "here is my post".

There is a second consequence that channel owners consistently underestimate. Telegram's own channel FAQ says of the view counter: "Views from forwarded copies of your messages are also included in the total count. This way you can see how far it has spread." So when your post is forwarded, the views on the copy feed the original's counter. If you mirror your own channel with real forwards, your numbers consolidate. If you mirror it with copies, they split.

A copy arrives clean

The Bot API's copyMessage is described as "analogous to the method forwardMessage, but the copied message doesn't have a link to the original message." No header, no attribution, no link. The destination sees a normal post.

Copying is more restricted than forwarding, and the docs are explicit about it: "Service messages, paid media messages, giveaway messages, giveaway winners messages, and invoice messages can't be copied. A quiz poll can be copied only if the value of the field correct_option_ids is known to the bot." So a mirror built on copies will skip things a mirror built on forwards would have carried, and it will do it silently unless you log the skips.

The middle option almost nobody knows about

On the user side of the protocol there is a third setting. The forward call takes a flag called drop_author, which the Telethon documentation describes as "Whether to forward messages without quoting the original author", and a companion flag drop_media_captions that strips captions and requires drop_author to be set as well. That is a real forward at the protocol level, executed without the header. It is how most polished mirrors look native without falling into the copy method's restrictions.

One caveat straight from the protocol's error list: hiding the author on a quiz is not free. The error QUIZ_ANSWER_MISSING reads "You can forward a quiz while hiding the original author only after choosing an option in the quiz." Small thing, but it is the kind of small thing that stops a nightly job at 3am.

How to choose

Forward with the header when you are curating and want to credit, when you want the views to consolidate on the source, or when the source is your own channel and you want subscribers to be able to walk back to it. Forward with the author dropped when the mirror is meant to read as your own channel and you still want media, albums and polls to travel intact. Copy when you need to rewrite the caption on the way through, because copyMessage accepts a new caption and keeps the original only "If not specified".

What Telegram gives you before any tool

Two native features do a surprising amount of this job, and both are free. It is worth knowing exactly where they stop, because a lot of people install a bot to do something the app already does.

Manual forwarding, in bulk

Select multiple messages, forward them together, and Telegram keeps albums grouped. You can also strip the sender name at send time on most clients. For a one-off move of a few hundred messages this is genuinely the right tool, and it costs nothing. It is also the only method on this list that never gets rate limited in a way that hurts you, because a human tapping through a chat is exactly the traffic pattern the platform expects.

The linked discussion group, which is a real auto forward

Telegram's channels FAQ describes it plainly: "You can add a discussion group chat to the channel, and your subscribers will see a comment button for each post in the channel. Comments show up in a thread of their own and also land in the discussion group to keep everyone in the loop."

That last part is the bit people miss. Every channel post lands in the linked group automatically, with no bot and no script. The Bot API even marks these messages with a dedicated field, is_automatic_forward, described as "True, if the message is a channel post that was automatically forwarded to the connected discussion group". If your goal was "my channel posts should also appear in my group", you are already done, and the comment threads are a bonus.

Where it stops: one channel to one linked group, in that direction only, with no filtering and no rewriting. It cannot mirror somebody else's channel, cannot feed two destinations, and cannot skip the posts you would rather not repeat.

Restrict Saving Content, the setting that breaks most tools

When Telegram introduced content protection it described the feature this way: "Group and Channel owners who want to keep their content members-only can restrict message forwarding from their chat, which also prevents screenshots and limits the ability to save media from posts." The path is in the same post: "Group or Channel Info page > Group / Channel Type > Restrict Saving Content."

Two consequences follow, and they matter for every method below. First, on your own channel this is a switch you can flip to stop other people mirroring you. Second, on somebody else's channel it is a wall: the Bot API states outright that "Service messages and messages with protected content can't be forwarded", and the chat object exposes has_protected_content, "True, if messages from the chat can't be forwarded to other chats". At the protocol level the failure is explicit, a 406 CHAT_FORWARDS_RESTRICTED with the description "You can't forward messages from a protected chat."

Method 1: manual forwarding, and exactly where it breaks

Worth stating properly rather than dismissing, because for a large number of people it is the correct answer and they talk themselves out of it.

Manual forwarding wins whenever the volume is bounded and the timing is loose. Moving an archive, seeding a new channel, pulling the twenty posts worth keeping out of a group that is being closed. You keep full control over what travels, you see every message as it goes, and there is no session, no token and no server to maintain.

The three failure points

Latency. A mirror that depends on you noticing is a mirror with a delay measured in hours. If the destination audience is meant to see news at the same time as the source audience, manual is finished before it starts.

Fatigue. Forwarding is boring, so it degrades. Week one is complete, week three is the important ones, week six is nothing. Every manual process that runs daily decays the same way, and the failure is silent because nothing errors, it just stops happening.

Edits and deletions. When the source edits a post, your forwarded copy does not change. You have to notice and redo it. In practice nobody does, so a manual mirror slowly fills with stale versions of posts that have since been corrected.

If those three do not bother you, stop reading and go forward your messages. If any of them does, you need something that runs without you, and that means picking one of the next three.

Method 2: a bot you run yourself

The obvious route. Create a bot with @BotFather, put it in both chats, have it forward what it sees. It is well documented, it is officially supported, and it fails in ways that are easy to reason about. It also has a hard boundary that decides whether it fits your case at all.

What the bot has to be able to see

A bot receives channel posts only where it is a member. Telegram's bot FAQ puts the boundary plainly, listing "All messages from channels where they are a member" among what bots receive. In practice that means you add the bot to the source channel, usually as an administrator, and the updates arrive as channel_post, described in the API as "New incoming channel post of any kind - text, photo, sticker, etc." Edits arrive separately as edited_channel_post, "New version of a channel post that is known to the bot and was edited".

This is the boundary: if you cannot add your bot to the source, this method is over. You cannot point a bot at a public channel you do not administer and have it read the feed. That single fact is why so many "auto forward bot" projects end up on the user-account route instead.

The four calls that do the work

forwardMessage forwards one message and returns the sent message. The docs note that "Service messages and messages with protected content can't be forwarded."

forwardMessages takes "a JSON-serialized list of 1-100 identifiers", requires that "The identifiers must be specified in a strictly increasing order", and states that "If some of the specified messages can't be found or forwarded, they are skipped." Crucially for anyone mirroring media: "Album grouping is kept for forwarded messages."

copyMessage sends the message without a link back, and accepts a replacement caption.

copyMessages is the bulk version, also 1 to 100 ids, and it keeps album grouping too.

Both bulk calls return an array of message ids rather than full message objects, which matters more than it sounds: if you want to keep a map between source ids and destination ids so you can propagate edits later, the bulk calls give you exactly what you need and the single calls give you a little more.

The limits, quoted rather than guessed

Telegram publishes these, so there is no need to repeat folklore. From the bot FAQ: "In a single chat, avoid sending more than one message per second." Then: "For bulk notifications, bots are not able to broadcast more than about 30 messages per second, unless they enable paid broadcasts." And for groups specifically: "In a group, bots are not be able to send more than 20 messages per minute."

Exceed them and you get 429 responses. The paid escape hatch exists and is documented in the API parameters: allow_paid_broadcast lets you "allow up to 1000 messages per second, ignoring broadcasting limits for a fee of 0.1 Telegram Stars per message", and the API notes that "In order to use this feature, a bot must have at least 10,000 Stars on its balance." For a channel mirror this is almost never relevant, because a mirror sends to one destination and the one-per-second rule is the one that binds.

The practical reading: a bot mirror is comfortable at normal channel volume. It gets uncomfortable when the source dumps a backlog, which is exactly what happens on your first run against an existing channel, and that is where a queue with a delay between sends stops being optional.

What a bot cannot fix later

Deletion has a hard wall. The API's own list of limitations begins: "A message can only be deleted if it was sent less than 48 hours ago." Everything else in that list is about rights, and the rights are obtainable, but the 48 hours are not. So a mirror that promises to delete copies when the source deletes the original can only keep that promise for two days.

Editing is friendlier. A bot can edit its own messages, so if you kept the id map you can propagate an edit indefinitely. It is one of the few places where the bot route is genuinely stronger than the alternatives, and it is the reason to keep that map even when you think you will not need it.

When Method 2 is the right choice

You own or administer the source. The content is not protected. You want something officially supported that you can hand to a developer, host anywhere, and debug from logs. If all four are true, build the bot and stop shopping.

Method 3: somebody else's forwarding bot

Search the query that brought most people here and the first page is full of ready-made bots and repositories. Some of them work. The question is not whether they work, it is what you are handing over and what happens when the person who built it loses interest.

What you actually hand over

If the tool is a bot you add to your channels, you are handing over read access to the source and posting rights on the destination, and the operator can see every post that passes through. For public sources that is a small concession. For a private channel or a paid community it is not, and it is worth being honest with yourself about which one you have.

If the tool asks you to log in with your phone number, it is not a bot. It is running a user account, which is Method 4, and the operator holds an authorised session on your account. That is a different level of trust entirely, and the interface being a chat window does not change it.

Five questions worth asking before you connect anything

Does it survive the source being protected? If the answer is yes and it is a bot, be suspicious, because the platform says no.

What happens on a backlog? Ask what it does when the source posts fifty messages in a minute. "It just forwards them" means you will meet the rate limits together.

Where does it run? A free bot with no visible business behind it is a bot that stops when the hosting bill arrives. Mirrors fail silently, so you find out days later.

Can you filter? Almost every mirror eventually needs to drop something, usually the source's own promotions. If filtering is not there on day one, it will not appear on day thirty.

Who has your session? If you had to log in, ask how to revoke it. The answer should be immediate and specific, and you should be able to check it yourself in the app under active sessions.

The honest case for using one

For a hobby channel mirroring a public source, a ready-made bot is fine and free is a fair price. Nobody should build infrastructure for that. The case against is narrow but real: private sources, paid communities, anything where a silent failure costs money, and anything you would be embarrassed to explain to your subscribers.

Method 4: a user account that mirrors

The route that removes the boundary from Method 2. Instead of a bot that must be added to the source, an ordinary account that is subscribed to the source the way any reader is. If you can see the channel in your app, the account can see it in code, and that single difference is why serious mirrors are built this way.

How it listens

A library like Telethon or Pyrogram connects with a user session and receives updates as they happen. You register a handler for new messages in a specific chat and forward or copy from inside it. There is no polling loop to write and no webhook to expose, which makes the whole thing shorter than people expect: the listening half is a handful of lines and all the real work is in the rules.

Forward, or send a copy

Telethon's documentation is unusually direct about the distinction, and it is the same distinction from earlier in this guide seen from the code side: "If you want to 'forward' a message without the forward header (the 'forwarded from' text), you should use send_message with the original message instead. This will send a copy of it."

Alongside that sits the flag route, drop_author ("Whether to forward messages without quoting the original author") and drop_media_captions ("Whether to strip captions from media. Setting this to True requires that drop_author also be set to True"). Between those two you can produce a mirror that looks entirely native without rebuilding every media type by hand.

The errors that will actually happen

406 CHAT_FORWARDS_RESTRICTED, "You can't forward messages from a protected chat." This is content protection, discussed below.

406 CHANNEL_PRIVATE, "You haven't joined this channel/supergroup." Usually means the account was removed, the invite expired, or the channel went private.

MessageIdInvalidError. Telethon documents it precisely: "if all messages are invalid (i.e. deleted) the call will fail with MessageIdInvalidError. If only some are invalid, the list will have None instead of those messages." A mirror that batches will meet this the first time the source deletes a post mid-batch.

SLOWMODE_MULTI_MSGS_DISABLED, which the protocol describes as slow mode being enabled so you cannot forward multiple messages at once. Groups with slow mode need the mirror to send one at a time, with waiting in between.

Flood waits. The client has a flood_sleep_threshold setting, 60 seconds by default, meaning short waits are absorbed automatically and longer ones are raised to your code. A mirror should treat a long flood wait as a signal to slow the whole queue down, not as a single failed message to retry immediately. Retrying into a flood wait is how a small delay becomes a long one.

The costs nobody mentions in the tutorials

You are now running an account, not a bot, and an account carries obligations a bot never had. It has a session that lives in a file, and that file is the account: our own measurement on an empty session showed a small unencrypted database with five tables, so anyone who copies it has your access. It can be logged out from the app's active sessions list, which will stop your mirror without warning. It can be restricted if it behaves oddly. And it is subject to the same platform expectations as a person, which is why the rhythm section below matters more here than anywhere else.

None of that is a reason to avoid the method. It is a reason to run it on an account dedicated to the job rather than your personal one, and to know where the session file lives. Running several of them is its own discipline, which is what Account Manager exists for. We wrote a longer piece on the formats and the handover risks in session file versus TDATA, and the same reasoning applies here.

Protected channels: what the restriction really blocks

This is the single most common reason a working mirror suddenly stops, and the answers online are a mess, so it is worth being precise.

With Restrict Saving Content on, the platform refuses to forward the message. Not the app, the platform: the bot method says protected content "can't be forwarded", the chat exposes has_protected_content, and the protocol answers a forward attempt with CHAT_FORWARDS_RESTRICTED. There is no parameter that overrides it and no admin right that unlocks it for outsiders. Anyone selling you a bot that "bypasses forwarding restrictions" is either not using the forward call at all, or lying.

What the restriction does not do is make the content invisible to members. A member can see every post, and anything a member can see, code running as that member can read. That is the whole trick, and it is not a hack: a mirror built on a member account reads the message and posts its own new message with the same text and the same media, rather than asking the platform to forward. The result is a copy rather than a forward, which means no header, no link back, and no view counted on the original.

Worth saying plainly: the setting exists because a channel owner wanted their content to stay with members. Working around it on somebody else's paid channel is a decision with an owner on the other side of it, and the takedown section below is where that story usually ends. On your own channels, or on sources you have permission to republish, it is simply the mechanism that makes the mirror possible. Our longer walkthrough of the mechanics is in cloning a restricted channel.

Keeping the mirror in sync: edits, deletions, albums and pins

Getting messages across is the easy half. Keeping the destination honest over months is where mirrors quietly rot.

Edits

Edits arrive as their own update, so a mirror can catch them. Whether it can act on them depends on whether it kept a map from source message id to destination message id. Without the map, an edit is unactionable: you know something changed and you have no idea which of your five thousand posts to change. Build the map on day one even if you do not use it yet, because it cannot be reconstructed later.

Deletions

Two walls here. The first is that deletion events are not delivered as reliably as edits, so a mirror may simply never learn. The second is the Bot API's flat statement that a message can only be deleted if it was sent less than 48 hours ago. On the user-account side that limit does not apply the same way, which is one of the few places a user-account mirror is straightforwardly more capable.

The practical answer for most people: decide the policy up front and tell your audience. Either the mirror deletes what it can within the window and leaves older copies alone, or it never deletes and the destination is an archive. Both are defensible. Silently doing the first while implying the second is not.

Albums

Media groups are the classic bug: ten photos posted as one album arrive as ten separate updates, and a naive mirror posts ten separate messages. The bulk calls solve this on the bot side, since the API states plainly that "Album grouping is kept for forwarded messages" and the same for copies. On the user side you either forward the group in one call or buffer briefly and send them together. Either way, test it, because a mirror that shreds albums looks broken to every reader.

Pins, reactions and comments

None of these travel. A pinned post in the source is an ordinary post in the destination. Reaction counts do not transfer. Comment threads belong to the source's linked group and cannot be mirrored, only linked to. If your destination audience expects the discussion, keep the forward header so they can reach it.

Filtering: the part that makes a mirror worth reading

A mirror that copies everything is a duplicate. A mirror that copies the right things is a product. The filters that earn their keep, roughly in order of how often they are needed:

Dropping the source's promotions

Most channels advertise, and their ads are not your ads. Matching on the obvious markers catches most of it, and the rest is a small keyword list you maintain by hand for a fortnight and then rarely touch.

Stripping or replacing links

Forwarding a competitor's referral link is worse than not forwarding at all. Stripping links entirely is blunt but safe; replacing specific domains is better and only slightly harder.

Media type gates

Text only, no voice notes, no stickers. Cheap to implement and it removes a whole class of noise, especially when the source is a group rather than a channel.

Keyword routing

One source, several destinations, chosen by content. This is where a mirror stops being a copy machine and starts being an editor, and it is the feature people build custom tools for.

Author filters in groups

When the source is a group, most of the traffic is conversation and you probably only want one or two people. Filtering by sender turns an unusable firehose into a clean feed.

Rhythm: what actually stops a mirror

Almost nobody gets stopped for the total number of messages in a day. They get stopped for the shape of the traffic, and the two most common shapes are both self-inflicted.

The first-run backlog. You point a fresh mirror at a channel with four thousand posts and it tries to move all of them. On the bot side you meet the documented limits immediately. On the account side you meet flood waits, and if the code retries into them, the wait grows. Backfill slowly or not at all; there is rarely a real reason the destination needs history from before it existed.

The retry storm. One message fails, the code retries, it fails again, the loop tightens. We caused exactly this on our own infrastructure and it cost us real memory before we caught it: a connection was being refused, the client retried on a default of five attempts, and the same session reconnected six times a minute for hours. The fix was two lines, fewer retries plus a cooldown that parks a failing session for five minutes, and the lesson generalises. A failing mirror should get slower, not faster.

Beyond that, the ordinary hygiene applies: one account per job rather than one account running six mirrors, a delay between sends that looks like a person rather than a loop, and no bursts at exactly the same second every hour. If the account is also doing outreach, the account itself is under a different kind of pressure and the reasoning in our account safety guide applies before any of this does.

Media, size and quality

Forwarding and copying both move media by reference, which is why they are fast and why quality is preserved exactly. Re-uploading, which is what a mirror has to do when it cannot forward, is a different operation: the file comes down and goes back up, and the ceiling is Telegram's file limit, documented in the FAQ as files "of up to 2 GB each" and "up to 2 GB in size each (or 4 GB with Premium)".

Three practical consequences. Large video posts turn a mirror that was doing no real work into one that needs bandwidth and disk. A mirror that re-uploads should stream rather than buffer whole files if it is running on a small server. And re-uploaded media gets a new file id, so deduplication against the source stops working and you need your own record of what you have already sent.

The duplicate problem, and why rewriting exists

A mirror that reposts text verbatim produces a channel that is, to any reader who follows both, redundant. That is not a platform penalty, it is an audience one: people unsubscribe from the copy.

There are three honest ways out. Curate, so the destination carries a fraction of the source and the selection is the value. Add, so every mirrored post arrives with a line of your own commentary. Or rewrite, so the information travels and the wording is yours. Rewriting is the one people mean when they talk about "unique" mirrors, and it is also the one that turns a mirror into something you can defend when the source notices.

Translation is the strongest version of the same idea, and the one with the clearest business case. A channel in English mirrored into Spanish is not a duplicate of anything; it is the only version of that content its readers can use. If you are going to run a mirror at all, this is the shape that is worth running, and it is why translation sits inside our own mirroring tool rather than beside it.

Copyright and the takedown path

People assume this is theoretical. It is not, and Telegram documents the path in its own FAQ: "If you see a bot, channel, sticker set, or other content that is a part of Telegram's public platform and is infringing on your copyright, kindly submit a complaint to dmca@telegram.org." The same answer draws the line clearly: "Private groups and chats on Telegram are private amongst their participants. We do not process any requests related to them."

So the exposure depends on what you built. A private mirror for your own team is outside the process entirely. A public channel that reposts another public channel is inside it, and the outcome is not a warning, it is the channel. Telegram states elsewhere on the same page that it processes "legitimate requests to take down illegal public content (e.g., sticker sets, bots, groups and channels)".

None of that is legal advice, and it is a description of a documented process rather than an opinion about your case. The practical version is short: mirror your own channels freely, mirror with permission when it is somebody else's, and if you are building a public channel entirely out of one other channel's posts, understand that the whole thing rests on the source not minding.

Before you turn a mirror on: the checklist

Ten minutes here saves the week where you discover the mirror has been posting nothing since Tuesday.

1. Source access. Can the thing reading actually see the source, and does that access survive a restart?

2. Protection status. Is Restrict Saving Content on? If yes, no bot will do it.

3. Attribution decision. Header, no header, or full copy. Decide once and be consistent.

4. Backfill policy. How much history, if any, and at what pace.

5. Album handling. Post ten photos in the source and confirm they arrive as one album.

6. Id map. Are you storing source id to destination id? Without it, edits are dead.

7. Edit policy. Propagate or ignore, and say which.

8. Delete policy. Remember the 48 hour wall on the bot route.

9. Filters. At minimum, a rule for the source's own promotions.

10. Rate discipline. A delay between sends and a backoff that gets slower on failure.

11. Failure alarm. Something that tells you the mirror stopped. Mirrors fail silently; that is their defining property.

12. Revocation. If a third party holds a session on your account, know how to end it before you need to.

Choosing between the four

Read it as a decision tree rather than a scoreboard. Can you add a bot to the source? If yes and the content is unprotected, build the bot. If no, you are on the user-account route whether you like it or not, and the only remaining question is whether you run it yourself or have it run for you.

The managed version of Method 4

Channel Clone is that fourth method packaged: it runs on account access rather than bot access, so a channel you can read is a channel it can mirror, including ones with saving restricted. What you configure is the pair, source and destination, and then the rules.

The parts that exist because we kept hitting them ourselves: media travels, so images, videos, documents and GIFs arrive with formatting intact rather than as bare text; text replacement and link stripping are built in, because the first thing every real mirror needs is to stop republishing somebody else's promotions; and translation covers 65 languages, which is the version of mirroring with an actual business behind it. There is an AI rewriting layer for people who want the information without the wording, which is the duplicate problem from earlier solved at the source.

Tiers are one-time rather than monthly: Starter at $290 for a single channel pair, Professional at $590 for five, Team at $990 for unlimited pairs, all with 12 months of updates and support included. The full comparison is on the pricing page, and there is a 24 hour trial with no card required if you would rather test the thing than read about it.

How to buy from us

Message @FloqalSupport on Telegram with the tier you want. You get the payment address in the same reply, and access follows shortly after payment lands. If you are not sure which tier fits, say how many source channels you are mirroring and we will tell you; the answer is usually Starter, and we would rather say so than sell you the middle one.

If you are running several accounts behind this, the operational side is a separate problem and we wrote about it in managing multiple accounts. And if what you actually want is to automate your channel more broadly rather than mirror another one, channel automation is the wider view.

Frequently Asked Questions

Can a bot auto forward from a channel it is not in?

No. Bots receive messages from channels where they are a member, so if you cannot add the bot to the source, the bot route is closed. This is the single biggest reason people move to a user-account mirror.

How do I forward without the "Forwarded from" header?

Three ways. On the bot side, use the copy method, which the docs describe as analogous to forwarding "but the copied message doesn't have a link to the original message". On the user side, forward with the drop author flag, which forwards "without quoting the original author". Or send a new message built from the original content, which is what any tool does when forwarding is blocked.

Why did my mirror stop working on one channel but not the others?

Most often the source turned on Restrict Saving Content. The protocol error is explicit: you cannot forward messages from a protected chat. Check the source's info page, or test by trying to forward one post by hand.

Can anything bypass forwarding restrictions?

Not the forward operation itself, no. What works is being a member and republishing the content as a new message, which is a copy rather than a forward and therefore carries no link back and adds no views to the original. Any tool claiming to bypass the restriction with a bot is describing something the platform does not allow.

Do forwarded views count for the original channel?

Yes for real forwards. Telegram's channel FAQ says views from forwarded copies are included in the original's total count. Copies do not do this, so mirroring your own channel with copies splits your numbers in two.

How many messages can I forward at once?

The bulk bot methods take 1 to 100 message ids per call, and the ids must be in strictly increasing order. Anything that cannot be forwarded within that batch is skipped rather than failing the whole call.

What are the rate limits?

Telegram publishes three: avoid more than one message per second in a single chat, roughly 30 messages per second for bulk broadcasting, and no more than 20 messages per minute in a group. For a mirror the first is usually the binding one, since everything goes to a single destination.

Will the mirror update when the source edits a post?

Only if it stored which destination message corresponds to which source message. Edits arrive as their own update, so the information is there; without the id map there is nothing to apply it to. Ask any tool you are considering whether it keeps that map.

Can it delete a copy when the original is deleted?

On the bot route, only within 48 hours, because a bot can only delete messages sent less than 48 hours ago. On the user-account route it is generally possible, but delivery of deletion events is less reliable than edits, so treat it as best effort.

Do albums stay grouped?

With the forward and copy methods, yes: the documentation states album grouping is kept. A mirror that rebuilds messages one by one has to buffer and regroup them itself, and this is the most common visible bug in home-made mirrors.

Is auto forwarding against Telegram's rules?

The mechanics are supported: forwarding and copying are documented API methods and the linked discussion group forwards channel posts automatically. What draws enforcement is what you mirror and how fast. Republishing a channel that objects has a documented path that ends at dmca@telegram.org, and moving thousands of messages in minutes gets you rate limited regardless of intent.

What is the difference between a channel mirror and a clone?

Mirroring is ongoing: new posts flow as they appear. Cloning usually means the one-time copy of what already exists. Most people want both, the history once and the new posts forever, and the two halves have different failure modes. We covered the one-time side in how to clone a Telegram channel.

Can I mirror one source into several destinations?

Yes, and it is where routing rules matter. Sending the same post to five places is trivial; deciding which of the five each post belongs in is the actual feature. Watch the rate limits when one incoming post becomes five outgoing ones.

Can I mirror a group instead of a channel?

Yes, with two caveats. Groups carry conversation, so without an author or keyword filter you will relay noise. And groups with slow mode enabled reject multi-message forwards, so the mirror has to send one at a time.

Does the mirror need its own account?

For the user-account route, it should have one. An account running an unattended mirror is doing something visible and repetitive, and mixing that with your personal messaging or with outreach puts both at risk on one identity.

What happens if the source channel is deleted?

The mirror stops receiving updates and your destination keeps everything already posted. This is a genuine argument for mirroring: a destination you control is a backup that survives the source disappearing, provided the media was re-uploaded rather than forwarded by reference.

How fast is a mirror in practice?

A listener on a user account or a bot receiving channel posts sees a message essentially as it appears, so the delay is whatever your own queue adds. Deliberate delay is often the right choice anyway: an instant echo is obvious to anyone reading both, and a short gap costs nothing.

Can I add my own commentary to each mirrored post?

Yes on the copy route, since the copy method accepts a new caption and a rebuilt message can carry whatever you want. Not on a plain forward, which arrives exactly as it left. This is the cheapest way to stop a mirror from reading like a duplicate.