Do supergroup messages have permanent links?

Yes, because message IDs in a supergroup are chat-scoped rather than per-account. Everyone sees the same message with the same ID, so t.me/c/ / is a stable permalink for private groups, and t.me/ / for public ones. Note that the /c/ form uses the raw channel ID with no -100 prefix, so a Bot API chat_id has to be converted before you can build the URL.

GLOSSARY

What is a Supergroup?

A supergroup is a Telegram group implemented as a channel object with the megagroup flag set, which is what gives it up to 200,000 members, permanent shared history, granular admin rights, and chat-scoped message IDs. Basic groups, capped at 200 members, are a different object type in a different ID namespace entirely.

Try Pinlyx free See live demo

Free forever plan · No credit card required · Cancel anytime

Quick definition

In a single sentence: a supergroup is a channel that lets everybody speak.

What it means

Telegram has three conversational containers, and only two of them are what people mean by "group".

A basic group is the small one you get when you select a few contacts and start a chat. In the API it is a chat object, it holds up to 200 members, and it is deliberately simple.

A channel is a broadcast surface where admins post and everyone else reads.

A supergroup is the same channel object as a broadcast channel, with the megagroup flag set. That single flag is the whole distinction at the protocol level, and it is why supergroups inherit every piece of channel infrastructure: the 200,000 member ceiling, the shared permanent history, granular admin rights, optional public usernames, and chat-scoped message IDs.

The practical consequence for anybody writing code is that supergroups live in the channel ID namespace, not the group one. That is where the -100 prefix in Bot API chat IDs comes from, and it is why a basic group and the supergroup it becomes have no numeric relationship whatsoever.

Migration is a replacement, not an upgrade

When a basic group crosses its limits or an admin enables a supergroup-only feature, Telegram performs a migration. The word makes it sound gentle. It is not.

Telegram creates a new channel, moves the members, and deactivates the old chat. The old chat receives messageActionChatMigrateTo(channel_id), the new one opens with messageActionChannelMigrateFrom(title, chat_id), and those two service messages are the only bridge between the old ID and the new one. Over the Bot API the same event appears as a 400 error whose parameters object carries migrate_to_chat_id.

For a CRM this is a referential-integrity event. Conversations, notes, assignments and pipeline cards all key off the chat ID, and after migration that key points at a chat that will never receive another message. The symptom is a customer who appears to have gone quiet. The cause is a dead foreign key.

What you can and cannot read from a large group

Supergroups are where the interesting audiences live, which makes member data the most requested and most misunderstood capability on Telegram.

channels.getParticipants accepts a filter, and the filters do different jobs: recent members, a search by name, admins, bots, kicked and banned users, and contacts. The method exists over MTProto only; the Bot API has no equivalent at all.

Two limits shape what is actually possible. First, there is a server-side cap on how deep a plain recent-members query can page, in the low thousands, so scanning a 200,000-member group by incrementing an offset simply stops returning rows long before you reach the end. The workaround is partitioning: instead of one deep scan, issue many shallow search queries with different prefixes, each of which returns its own shallow page. Second, Telegram has restricted participant listing for non-admins in large groups, so a great many calls come back with CHAT_ADMIN_REQUIRED no matter how you page.

The honest summary: for groups you administer, you can enumerate members. For large groups you merely joined, you can usually sample them, not export them. Any tool claiming to dump a complete 200,000-member list is describing something the API does not do.

Moderation primitives worth knowing

Supergroup moderation is not one permission, it is two sets of flags.

Admin rights cover changing chat info, deleting messages, restricting members, inviting users, pinning messages, adding other admins, managing video chats, managing topics and posting anonymously. Up to 50 administrators can hold them, each with a different combination.

Banned rights work as restrictions on ordinary members: whether they can view messages at all, send messages, send media of specific kinds, embed links, send polls, change chat info, invite users, pin, or manage topics. Crucially each restriction carries an expiry timestamp, which is how a timed mute exists as a first-class concept rather than as something your bot has to schedule and remember.

Slow mode sits alongside them, limiting how often each member may post. Telegram offers a fixed set of intervals: 10 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes and 1 hour. When a member posts too soon the server returns SLOWMODE_WAIT_X, which looks like a flood wait and is easy to misread as one. It is not: it is a property of the chat, not of your account, and it says nothing about your standing with Telegram.

Why it matters

Most business conversation on Telegram happens in supergroups: customer communities, regional trade groups, industry channels with comments enabled, and internal team chats. If your CRM treats them as a single undifferentiated "group" type, several things break at once.

Permalinks stop working, because the t.me/c/ form needs the raw channel ID rather than the prefixed one. History import silently returns nothing for basic groups, because there is none to import. Migration orphans records. And topics, which only exist on supergroups, mean that the chat ID alone is no longer a unique conversation key at all.

Common mistakes

Assuming "group" means one thing. The Bot API reports two chat types and they behave differently.
Ignoring migration events. The new chat ID is handed to you, in the service message or in the error parameters. Use it.
Paging getParticipants by offset alone. You will hit the depth cap and quietly stop receiving rows. Partition by search instead.
Treating SLOWMODE_WAIT as an account problem. It is a chat setting. Slowing the whole account down is the wrong response.
Building t.me/c links from a Bot API chat_id. The -100 prefix has to be removed first.
Storing message IDs without their chat. Chat scoping makes them unique within a supergroup and nowhere else.

Related concepts

Peer ID: why supergroups carry a -100 prefix and basic groups do not.
Forum topic: threads inside a supergroup, and what they do to your conversation key.
Invite link hash: how people get into a private supergroup.
Access hash: what enumerating members actually gives you.
MTProto: the API where participant listing exists at all.
Flood wait: the account-level cousin of SLOWMODE_WAIT.

Cheat sheet · migration and member listing

The two calls that break most integrations.

One hands you a new ID you have to store. The other stops returning rows without telling you why.

// 1. A basic group became a supergroup. The Bot API tells you where it went.
{
  "ok": false,
  "error_code": 400,
  "description": "Bad Request: group chat was upgraded to a supergroup chat",
  "parameters": { "migrate_to_chat_id": -1001234567890 }
}
// Store the new id, re-point every related row, retry once. Do not drop the record.

// 2. Naive member listing. Stops producing rows long before the group ends.
for (let offset = 0; offset < 200000; offset += 200) {
  await channels.getParticipants({
    channel: inputChannel(id, hash),
    filter:  channelParticipantsRecent(),
    offset, limit: 200, hash: 0
  });
}
// Two ways this fails:
//   - a server-side depth cap: past a few thousand you get empty pages
//   - CHAT_ADMIN_REQUIRED in large groups you do not administer

// The workaround for the depth cap: partition by search prefix
for (const q of ['a','b','c','d', /* ... */ 'aa','ab' /* ... */]) {
  await channels.getParticipants({
    channel: inputChannel(id, hash),
    filter:  channelParticipantsSearch({ q }),
    offset: 0, limit: 200, hash: 0
  });
}
// Many shallow queries, each inside the cap, deduplicated client side.

200,000 members

The supergroup ceiling. Basic groups stop at 200.

Chat-scoped message IDs

Identical for every member, which is what makes permalinks possible.

Listing has a depth cap

Deep offsets return nothing. Partition by search instead of paging.

Integration checklist

Six things to get right about supergroups.

Store the peer type explicitly. Never infer group versus supergroup from the ID sign.
Handle migration events and re-point every related record at the new channel ID.
Build t.me/c permalinks from the raw channel ID, not the -100 prefixed one.
Partition member queries by search prefix instead of paging into the depth cap.
Distinguish SLOWMODE_WAIT from FLOOD_WAIT. Only one of them is about your account.
Expect CHAT_ADMIN_REQUIRED on large groups and report it honestly rather than retrying.

Watch out for

An empty page is not the end of the list.

The most damaging bug in Telegram group research is also the quietest: a paging loop that keeps incrementing an offset, receives an empty page well before the real end, and concludes the group has 3,000 members when it has 90,000. Nothing throws, nothing logs, and the resulting audience file looks perfectly plausible. Always compare what you collected against the participant count the chat itself reports, and treat a large gap as a failed extraction rather than a finished one.

Supergroups: FAQ

What changes the moment a Telegram group stops being a basic group.

A basic group is a small, simple chat object capped at 200 members with all-or-nothing admin powers and no shared history for people who join later. A supergroup is a channel object with the megagroup flag, which raises the ceiling to 200,000 members and adds permanent history, per-right admin permissions, slow mode, per-user restrictions with expiry dates, optional public usernames and topics. In the Bot API they even report different chat types: "group" versus "supergroup".

Because the upgrade does not convert the object, it replaces it. Telegram creates a brand new channel with a new ID in a different namespace, migrates the members across and deactivates the old chat. The only link between the two is a pair of service messages: messageActionChatMigrateTo in the old chat and messageActionChannelMigrateFrom in the new one. Over the Bot API the same event surfaces as a 400 error carrying migrate_to_chat_id in its parameters. Handle it or your conversation history silently detaches.

Usually not, and this surprises people who read the API docs and expect otherwise. channels.getParticipants has a server-side cap on how deep you can page, so a group with tens of thousands of members will only ever hand back the first several thousand through a plain recent-members query. Telegram has also restricted participant listing for non-admins in large groups, so many calls come back with CHAT_ADMIN_REQUIRED. The documented workaround for the depth cap is partitioning by search: issue many queries with different prefixes rather than one deep scan.

Slow mode limits how often each member may post, and Telegram offers a fixed set of intervals rather than a free-form number: 10 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes and 1 hour. It is set with channels.toggleSlowMode. When a member posts too soon the server answers with SLOWMODE_WAIT_X, which looks like a flood wait but is chat-level rather than account-level, so it says nothing at all about the health of your account.

Yes, because message IDs in a supergroup are chat-scoped rather than per-account. Everyone sees the same message with the same ID, so t.me/c/<raw_channel_id>/<message_id> is a stable permalink for private groups, and t.me/<username>/<message_id> for public ones. Note that the /c/ form uses the raw channel ID with no -100 prefix, so a Bot API chat_id has to be converted before you can build the URL.

Fifty. What matters more in practice is that admin power is not a single switch: each administrator carries a set of rights covering things like changing chat info, deleting messages, restricting users, inviting members, pinning, managing topics and adding other admins. Restrictions on ordinary members work the same way and can carry an expiry date, which is how a timed mute is implemented rather than a permanent ban.

Keep reading

Peer ID

Why supergroups live in the channel namespace.

Forum topic

Threads inside a supergroup, and the conversation key they break.

Invite link hash

How members get into a private supergroup.

Access hash

What member enumeration actually gives you afterwards.

Telegram scraping guide

A limit-aware workflow for extracting group members.

Telegram CRM

Turning group members into contacts with a source attached.

Ready to ship

Every group type, handled correctly.

Pinlyx tracks migrations, builds working permalinks, and tells you honestly how much of a group it could actually read.

Start free Talk to sales

Free forever plan · GDPR-ready · No credit card required