Pulling Members Out of a Competitor's Telegram Group: Where the Limits Bite

You found a competitor group with 60,000 members in your exact niche. The plan writes itself: pull the list, add them to yours, done by Friday.

You will get somewhere around 3,700 of them, it will take longer than a week, and roughly half the accounts you use to do it will be dead by the end. None of that is a tooling problem. It is five separate hard limits stacked on top of each other, and the sooner you know where they sit, the sooner you stop planning campaigns around a number that was never reachable.

Limit one: channels do not have a member list you can read

Start here, because it kills a large fraction of these plans outright.

A broadcast channel hides its subscriber list from everyone except admins. Call channels.getParticipants against a channel you do not administer and you get CHAT_ADMIN_REQUIRED. There is no workaround, no library that gets around it, and no reseller who has one. If your competitor runs a channel, their subscriber list is not available to you at any price.

Supergroups are different. Members can generally see the member list - which is why source-group campaigns work against groups and not channels. But even that is now conditional: group admins can turn on a setting that hides the member list from non-admins. When it is on, you are back to CHAT_ADMIN_REQUIRED.

So the first thing to do with any target is check whether it is a group or a channel, and if it is a group, whether members are visible. Two minutes with a client account, before you plan anything.

Limit two: the enumeration cap

Say you have a visible supergroup with 60,000 members. You will not get 60,000 user objects.

Paginating getParticipants with an empty filter stops returning results once the offset passes roughly 10,000. The group is bigger than that; the API will not walk past it. This is a deliberate ceiling, not a bug you can retry your way through.

There is a partial workaround: getParticipants accepts a search string, so you can slice the population by querying a, b, c, then two-letter prefixes, and union the results. It gets you past 10,000. It never gets you everyone, because names are unevenly distributed and because every additional query is another chance at a flood wait. In practice, aggressive prefix slicing on a 60,000-member group might surface 15,000-20,000 unique users and cost you hours of wall-clock time sitting out FLOOD_WAIT responses.

There is a second, better path that people overlook: enumerate message senders instead of members. Walk the group's recent history and collect the user IDs of people who actually posted. The pool is far smaller - maybe 3-8% of the member count - but every one of them is demonstrably active, which is worth more than ten times as many dormant IDs. If you are optimising for view rate rather than headcount, do this.

Limit three: privacy settings block the add

Every Telegram user has a setting for who may add them to groups: Everybody, My Contacts, or Nobody, with per-user exceptions. Anyone who has moved off the default returns USER_PRIVACY_RESTRICTED when you try to add them, and the attempt still counts against your rate budget.

The share who have moved off the default varies enormously by population. A crypto-adjacent group where everyone has been spam-added forty times will be heavily locked down. A casual shopping community much less so. Assume 30-50% and measure your own rate on the first thousand attempts.

Two more errors show up in the same place and belong in your model:

USER_NOT_MUTUAL_CONTACT - adding certain users to a supergroup or channel requires a mutual contact relationship you do not have.

USER_CHANNELS_TOO_MUCH - the target has already joined the maximum number of groups and channels their account allows. Common among exactly the people who join a lot of deal groups, which is to say your best prospects.

Limit four: your accounts have a throughput ceiling and a lifespan

Adding is rate-limited at the account level in two layers. FLOOD_WAIT_X tells you to wait X seconds and is recoverable. PEER_FLOOD means the account has been flagged for spam behaviour and is the beginning of the end - after that comes a restriction that may or may not be appealable through Telegram's spam bot.

A warmed account working conservatively handles roughly 20-40 successful adds a day. Push past that and you buy a day of extra output at the cost of the account's remaining life. Under sustained load, plan for a median useful lifespan measured in days.

Failed attempts count. A privacy-blocked add still consumed a request and still moved the account toward a flag, which means your effective throughput is roughly successful adds × (1 / success rate) worth of requests, and a 45% success rate means you burn accounts more than twice as fast as a naive model predicts.

Limit five: they can leave

An added member did not ask to be there. Some fraction opens the group, does not recognise it, and leaves within the hour. Measure at 72 hours, not at delivery. Twenty percent early churn is a reasonable planning assumption and it is much worse if the group they land in is empty.

The whole funnel, with numbers

Source group advertising 60,000 members, visible member list, single source.

Stage	Rate	Remaining
Advertised members	-	60,000
Enumerable via API (cap)	~17%	10,000
Less bots and deleted accounts	−6%	9,400
Less overlap with your existing members	−8%	8,650
Less privacy-restricted	−40%	5,190
Less not-mutual-contact / channels-too-much	−10%	4,670
Less 72-hour churn	−20%	3,736

6.2% of the advertised headcount. That is the number to plan against.

The time cost: 5,190 successful adds at 30 per account-day is 173 account-days. Across a fleet of 20 working accounts that is roughly nine days of continuous operation, assuming nothing breaks, plus the enumeration time, plus the warming pipeline you needed before any of it started.

This is why briefs that name a single source group are a problem. If you need 10,000 members, one 60,000-member group cannot produce them - not slowly, not expensively, not at all. Eight to ten sources in the same vertical can, and the overlap between them is smaller than you would guess because most people are in fewer groups than you assume.

It is also the shape of what we sell, so weigh this accordingly: TeleReach fills a Telegram group from source groups you name - up to ten per order - or from our own US online-shopper pool, at $60 per 1,000 with volume rates above that. The reason we ask for up to ten links rather than one is the table above, and if the sources you name cannot physically yield the quantity you ordered, that is a conversation to have before delivery rather than after.

Before you run this, two things worth knowing

Bulk unsolicited adding sits against Telegram's terms on spam, and enforcement is real: the accounts doing the adding get limited, and a destination group that draws enough reports can be restricted, which for a public group means losing search visibility. That risk lands on your production asset, not on the throwaway accounts.

If you are storing user IDs, usernames and names of people in the EU or UK, you are processing personal data, and the fact that it came from a public group does not exempt you. Whether that matters to you is a call for you and a lawyer, not for a blog post, but it should not be a surprise later.

What usually goes wrong

Targeting a channel. Half the plans die here and it is discoverable in two minutes. Check group versus channel first.

Modelling advertised members as reachable members. The single most expensive mistake in this whole exercise. Everything downstream of the enumeration cap is a multiplication of numbers below one.

Running the adds from the account that owns the group. When it gets flagged, you lose admin access to your own asset. Use separate accounts, promoted with only the invite permission, and keep the owner account clean.

Ignoring failure codes. USER_PRIVACY_RESTRICTED, USER_NOT_MUTUAL_CONTACT and PEER_FLOOD mean completely different things and demand different responses - skip, skip, and stop immediately. Code that retries indiscriminately on any error will convert a recoverable flood wait into a permanent restriction.

Delivering into an empty room. Members added to a group with six messages in it leave at multiples of the normal rate. Thirty to fifty real posts and a few genuine conversations first, then adds - and stagger them so the group never appears to double overnight.

One source, one shot. Named sources exhaust. Line up ten, measure the yield of each on the first 500 attempts, and drop the ones returning a bad success rate rather than grinding through them.

Next step

Open the target group with a client account and answer three questions before you write any code: is it a group or a channel, is the member list visible, and how many of the last 200 messages come from distinct users. That last one tells you the size of the active-sender pool, which is the segment actually worth having.

Then multiply the advertised headcount by 6%, compare it to your target, and count how many more source groups you need. If the answer is more than one, send us the list and get a quote against it - we will tell you what those specific sources can yield before you spend a month finding out.