Telegram Invite Links: Expiry, Limits and Join Requests

Somebody tells you the link is broken. You open the chat, tap the invite link, and it works perfectly. They try again and it still fails. Neither of you is lying, and the reason is that you are not looking at the same link.

Telegram's invite system is far more structured than the single button in the interface suggests. A link is not an address. It is an object with an owner, a creation date, an optional expiry, an optional ceiling, an optional approval queue, an optional price, and a set of counters that record exactly who came through it. Almost none of that is visible unless you go looking, and almost every invite link problem is one of those fields doing precisely what it was set to do.

This article goes through what a link actually carries, the two settings the platform refuses to combine, what each refusal message means when a join fails, how the approval queue really works, what the counters can tell you about where your members came from, and how paid subscription channels turn out to be the same mechanism with a price attached. Every claim about the platform was pulled from Telegram's own API documentation on 8 August 2026 rather than remembered, and the numbers quoted are the published ones rather than figures someone saw on a screenshot.

There Is No Such Thing as the Group's Link

Every chat starts with one, and it is not special

A newly created group, supergroup or channel already has a default invite link, which the documentation calls the primary link. Nobody generates it and nobody has to. It is simply there, and for most small chats it is the only link that will ever be used. The important thing about it is not that it exists but that it is replaceable: generating a new primary link revokes the previous one automatically, in the same call, with no confirmation step in the protocol.

Each administrator generates their own

This is the sentence that explains most invite link confusion, and Telegram states it plainly: each administrator in a chat generates their own invite links, and a bot cannot use links generated by other administrators. There is no shared pool. When you and another admin both tap the same button, you get two different links to the same room, each recorded against its creator.

The consequence is that the phrase "the group link" is meaningless in a chat with more than one admin. It is always somebody's link. When a link stops working, the useful question is not what happened to the link but which admin made it, because that admin is the only person who can see its settings without going through the full administrator list.

You cannot even read somebody else's link

The restriction is stricter than most people expect. In the Bot API, the link field of an invite link object carries a note that if the link was created by another chat administrator, the second part of the link will be replaced with an ellipsis. You get the shape of it and not the working address. So an admin looking at a colleague's link sees a truncated string, cannot forward it, and cannot test it. This is deliberate, and it means a proper handover involves creating fresh links rather than passing existing ones along. Who may create and revoke links in the first place is a separate question, governed by the permission set we went through in our piece on what each admin right actually exposes.

Four Things a Link Can Carry

A name that only admins see

A link can be given a short label, capped at thirty two characters, and the underlying field is documented as a custom description for the invite link visible only to admins. Nobody joining ever sees it. That makes it the single most underused field in the whole system, because it is the only thing standing between you and six identical looking links in a list three months from now. Naming a link after the place it was posted costs five seconds and turns the counters described further down into actual information.

An expiry date

A link can be given a point in time after which it stops working, stored as a plain timestamp. A link without one carries a flag documented as meaning the invite has no expiration, which is the default state. Expiry is the setting people reach for first and it is the one that produces the most support messages, because a link that has expired looks exactly like a link that was never valid to the person holding it.

A usage limit

A link can be capped at a maximum number of users, and the documented range is one to ninety nine thousand nine hundred and ninety nine. The wording matters more than the number: the cap is on how many users can be members of the chat simultaneously after joining through that link. It is not a count of taps and it is not permanent consumption. If somebody joins through a capped link and later leaves, that seat comes back.

An approval requirement

A link can be set so that everybody arriving through it lands in a queue instead of the room. The flag is documented as meaning that users importing this link will have to be approved to join the channel or group. This is the setting that turns an invite link from a door into a doorbell, and it changes the economics of sharing a link publicly, because a leaked link with approval on costs you a queue rather than an invasion.

The Two Settings That Cannot Coexist

Approval or a ceiling, never both

Here is a detail that no interface explains and that almost every guide gets wrong by omission. If the approval flag is set, the member limit cannot be specified. The documentation states it in one line under the parameter, and it applies both when creating a link and when editing one. You may have an approval queue or a hard ceiling. You may not have both on the same link.

Why the platform draws the line there

The reason becomes obvious once you try to define the behaviour yourself. If a link had a ceiling of fifty and an approval queue, what should happen when the sixtieth person requests? Refuse them at the door, which makes the queue pointless? Queue them and then fail on approval, which wastes everybody's time? Count pending requests against the ceiling, which lets one abandoned request block a real member forever? There is no good answer, so the platform refuses the combination instead of picking a bad one.

What to do when you genuinely want both

Run two links. Use a capped link for the audience you trust and an approval link for the audience you do not, and give them different names so the counters stay readable. This is not a workaround, it is the intended shape: the system is built around many small links with narrow purposes rather than one link that tries to express a whole policy.

What "Expired" Actually Means

Two refusals that look identical from the outside

When a join fails, the person trying to join sees a generic failure. Underneath there are separate refusals with separate meanings. One says the invite link has expired and is returned with a different status code to the rest. Another says the invite hash is invalid. A third says the hash is empty. Three completely different situations, one identical screen.

The distinction is worth knowing because the fixes are opposites. An expired link was valid and stopped being valid, either because its expiry passed or because it was revoked, and the fix is to issue a new one. An invalid hash was never a working link for this chat, which usually means the address was retyped, truncated by a chat client, or copied out of a screenshot. Sending the same link again fixes the second case and does nothing at all for the first.

The refusal that means it worked

There is one entry in the join error table that is not a failure. The refusal that reports a join request was sent is documented with the text that you have successfully requested to join this chat or channel. It arrives on the same channel as every real error, and any tool that treats a non-empty error as a failure will report a successful request as a broken link. If you run anything automated against invite links, this is the single most likely reason your logs disagree with reality.

Where the link format itself matters

Telegram matches invite links against a published pattern, and what the system actually consumes is the hash at the end rather than the whole address. Both the short form beginning with a plus sign and the older form containing a path segment resolve to the same hash. This is why a link that has been through a chat client, a document, or a link shortener sometimes fails: the visible text survived and the hash did not.

The Ceilings That Are Not Yours

You have joined too many chats

One refusal reports that you have joined too many channels and supergroups. This is a per account ceiling and it is published in the client configuration rather than hidden: the default is five hundred, and a Premium account gets one thousand. Every supergroup and channel counts, including ones nobody has opened in a year. For anybody running outreach accounts this ceiling arrives far sooner than expected, and the fix is leaving chats rather than anything to do with your link. The wider mechanics of running several accounts under one roof are covered in our note on managing multiple Telegram accounts.

They have joined too many chats

A second refusal reports the same condition on the other side, meaning the person you are trying to add or approve has hit their own ceiling. Nothing about your chat, your link or your permissions is wrong, and no setting on your side will change the outcome. This one shows up during approval as well as during joining, which produces a confusing sequence where an admin approves somebody and that person still does not appear.

The room itself is full

A third refusal reports that the maximum number of users has been exceeded. This is the chat's own ceiling rather than either person's account ceiling. Between the three of them, most mysterious join failures in a large chat are explained without any reference to the link at all, which is why reading the actual refusal beats guessing every time. The same discipline applies when adding members directly, where the error codes are the whole diagnosis, as we set out in our guide to the limits on adding members.

Join Requests, and the Queue Nobody Staffs

Two ways to turn it on, and they are not the same

Approval can be attached to a single link, or switched on for the entire chat with a separate call that flips a flag on the chat itself. The difference is easy to miss and it decides your whole moderation load. Per link approval lets you keep a fast door for people you trust and a slow door for a public post. Chat wide approval means every arrival waits, including the ones you personally invited an hour ago.

What an admin actually receives

A human administrator gets an update saying the number of pending requests changed, along with a few recent requester identifiers, and is then expected to fetch the full list separately. A bot administrator gets a distinct update for each individual request, carrying the requesting user, the date, their short profile text and the exact link they used. That asymmetry is the reason bots are better at this job than people are. A person sees a badge with a number on it, while a bot sees each request as an event with its origin attached.

The bio arrives with the request

Each entry in the pending list carries the requester's profile text as it stood when they asked. For a group that gets any volume of junk requests, this single field does most of the filtering work, because accounts created to spam a group tend to share a profile text and a joining pattern rather than anything visible in a name. Reading the queue as a list of bios rather than a list of names turns twenty minutes of clicking into two.

The queue is also the cheapest defence available against the thing that actually damages a group, which is not one bad member but a wave of them arriving in the same hour and reporting each other. A group that has been through that already knows how expensive the cleanup is, and the restriction side of it is covered in our note on clearing a spam restriction.

The five minute window nobody uses

This is the most useful thing in the whole join request system and it appears in one sentence of the Bot API documentation. A bot handling a join request receives a private chat identifier for the requester, and it may use that identifier for five minutes to send messages until the request is processed, assuming no other administrator has contacted the user. Five minutes, before approval, to ask a question and get an answer.

What that enables is a real screening step rather than a guess. A paid community can confirm somebody actually purchased. A regional group can ask where they heard about it. A support channel can send the rules and require an acknowledgement. None of this requires the person to be a member first, and all of it disappears the moment the request is approved or declined. Newer builds tighten the loop further with a request query that must be answered within ten seconds, which is a hard deadline rather than a suggestion.

Approving in bulk, and per link

Requests can be approved or dismissed one at a time or in bulk, and the bulk call optionally takes a link, so you can accept everybody who arrived through one specific link while leaving the rest of the queue untouched. That is the correct response to a link that was shared in a good place, and it is also the fastest way to clear a queue after one link gets scraped, because you can approve the trustworthy source and decline the flood separately.

The race between two admins

There is a specific refusal for a request that was missing or had already been handled. In a chat with several active moderators this fires regularly and means nothing worse than two people reaching for the same request. It is worth recognising because it looks alarming in a log and is completely harmless. If it appears constantly rather than occasionally, the real problem is that nobody owns the queue.

What the Approval Log Remembers

Every approval is recorded with a name on it

Joining by approval produces its own entry in the administrative log, and that entry carries both the invite link used and the identifier of the admin who approved. The same information is attached to the person in the member list, which records who let them in. In a group with a moderation team this is the difference between an argument and a five second lookup.

Why that matters more than it sounds

Most groups that get into trouble do not get there through one dramatic breach. They get there through a slow accumulation of accounts that somebody waved through on a busy evening. Because approvals are attributed, a group can review the pattern rather than the incident, and the usual finding is that one moderator approves everything and the others approve almost nothing. That is a training conversation, not a security one, and it is invisible without the log.

Every Join Carries Its Link

Three counters, not one

A link records how many people joined through it, how many have used it to request and are still waiting, and for paid links how many joined and then left when their subscription lapsed. Three different numbers on the same object, and only the first is visible at a glance. The second tells you whether your queue is being worked. The third is a churn figure that most channels never look at because they do not know it exists.

Attribution without a tracking tool

Because every join carries the link that produced it, and links can be listed per admin along with how many each person created and how many were revoked, a chat has a built in attribution model. Make one link per place you post, name each one, and you can answer where your members came from without any external tool at all. This is the cheapest measurement available to a Telegram channel and almost nobody sets it up, because the naming field is invisible in the interface until you look for it.

What the platform will not tell you is what those members did afterwards, since the link counter stops at the moment somebody walks through the door. Pairing arrivals with what happens next is a separate job and the reason we keep Channel Analytics on a free tier, because a join count without a read count is the number that misleads people most often.

Reading a bad link honestly

Attribution only helps if you act on what it shows, and the usual finding is uncomfortable. A link that delivered four hundred joins and no readers is worse than a link that delivered nine, because the four hundred distort every other number you look at afterwards. The shapes that separate real growth from noise are the subject of our piece on how to tell whether a channel has been botted, and the same reading applies to a single link inside a healthy channel.

Revoke, Delete, and the Difference Between Them

Revoking closes the door and keeps the record

A revoked link can no longer be used to join, but information about it can still be fetched by asking for revoked links specifically. That is the right default. The link is dead, the history of who came through it is not, and you can still answer questions about a member who joined last year through a link you closed in spring.

Deleting removes it for good

There is a separate call to permanently remove a link, and another to clear out all revoked links belonging to one admin at once. That second one is the housekeeping tool after somebody leaves the team. Revoke what they made so it stops working, review the joins if you need to, then clear the list so the next person is not reading through fifty dead entries.

The primary link is a special case

Revoking the primary link does not leave the chat without one. A new primary is generated automatically in the same operation. This is worth knowing before a panic: if a link leaks and you revoke it, the room does not become unreachable, it becomes reachable through a different address that the leak does not contain.

The Preview Most People Never Notice

Some links let you look before joining

Checking an invite link normally returns a summary of the chat, its title, description, photo and member count, plus a few sample participants. For supergroups and channels the response can instead be a preview state, in which the client may fetch actual chat messages until a stated expiry time without joining at all.

What it means for a private channel

The practical reading is that a private channel is less private than its owner assumes. Anybody holding the link can see the title, the description, the photo, the member count and a handful of members before deciding anything, and in the preview case can read content without ever appearing in your member list. If the fact that a channel exists is itself sensitive, the link is the exposure, not the membership.

This is also the quiet reason private channels get copied. Content that can be read without joining can be read by anybody the link reaches, and the mechanics of what happens next are the subject of our piece on how channel cloning works. Restricting forwarding raises the cost of that without removing it, since the preview is a read rather than a forward.

Paid Channels Are Invite Links With a Price

The same object, one extra field

Telegram's paid subscription channels are not a separate product. They are an ordinary invite link created with a pricing structure attached, holding a period and an amount. Everything else on the page still applies. It has an owner, it can be revoked, it has counters, and it sits in the same list as every other link. Understanding that one fact removes most of the confusion about how paid channels work.

One allowed period, one published ceiling

The only permitted subscription period is thirty days, stated in the documentation as the exact number of seconds and repeated in the Bot API as a value that must always be that figure. There is no weekly tier and no annual tier. The price is set in Telegram Stars and the maximum is published in the client configuration as ten thousand, which the Bot API mirrors as a range of one to ten thousand. Creating a link outside those bounds returns a specific refusal for the price and another for the period.

What the subscriber goes through

Somebody opening a paid link gets the normal chat preview with the pricing attached and a pre generated payment form. The usual first steps of the payment flow are skipped because that form already exists. Once payment completes the user is added to the channel automatically, without a separate join step at all. Trying to join a paid link without paying returns a refusal saying the subscription must be paid for first.

Renewal, lapse and the second chance

The subscription renews itself at the end of each period, debiting the stars again and pushing the end date forward. Admins can see the end date for any individual member. If somebody leaves the channel without cancelling, the link reports that they may re join without paying again for the remainder of what they already bought, which is a genuinely fair piece of design and one that support teams should know about before refunding anybody.

The churn number sitting in plain sight

Admins can list only the users whose subscription expired, and the link itself carries a count of members who joined through it and then left for that reason. For a paid channel that is the single most important number in the product, more important than the join count, and it is available without any analytics tool. How this sits alongside the other ways a channel earns is covered in our piece on turning a channel into revenue, and the currency itself in our note on how Stars actually work.

When You Add Someone Directly Instead

Three reasons a direct add fails, and only one is about privacy

Adding a person straight into a chat rather than sending them a link returns a list of the people who could not be added, and each entry carries flags that say why. With no flags set, the add failed because of their privacy settings, and the documentation's own advice is to share an invite link with them through an ordinary message instead. A second flag means the add failed only because your account would need a Premium subscription to complete it. A third means their privacy settings blocked the add and your account would additionally need Premium to send them the link privately.

Why this matters before you buy a tool

Those three outcomes look identical in most interfaces, which is how people conclude that adding members simply does not work. Two of them are about a subscription on your side and one is about a setting on theirs, and only the last is genuinely closed. Any honest tool reports which of the three it hit rather than a bare failure count, and that reporting is what we built into Member Adder for exactly this reason. The wider arithmetic of what a single account can add in a day sits in our guide to member adding limits.

Folder Links Share a Whole Set at Once

A link that carries several chats

A chat folder can be exported as a link, and importing it adds the recipient to every chat in the set at once. The chats included must be public or ones where you hold the right to manage invite links, and a basic group named in such a link is converted to a supergroup automatically. It is the same family as an ordinary invite link and it appears in the same part of the documentation, which is why people who learn one usually miss the other.

The limits are published and they are low

The number of folder links you may create per folder is three by default and one hundred with Premium. The number of shared folders a person may join is two by default and twenty with Premium. Those are much tighter than the invite link limits and they are worth knowing before designing anything around them, because a free account can join two shared folders and no more.

The part that makes it a growth mechanic

A folder link is not a one time import. Clients that imported a folder check for additions at most once an hour, and anything you add to the folder later is offered to everybody who already imported it. That makes a shared folder the only structure on the platform where adding a new channel reaches an existing audience without a single message being sent. Leaving is symmetrical and deliberate: the client shows the person which chats came from the folder and lets them keep or drop each one.

That property makes folder links the natural companion to splitting one large community into several smaller rooms, since the split stops costing you reach. The trade offs in doing the split at all, and the alternative of keeping everybody in one place with separate threads, are laid out in our article on dividing a group that got too big.

A Link Policy That Survives Contact With Reality

One link per place, always named

Create a separate link for every place you post, and name each one after that place. This costs nothing, breaks nothing, and converts the counters from decoration into a report. It also means that when one link starts pulling junk, you revoke one link rather than resetting the door for everybody.

Expiry on anything public, approval on anything valuable

Put a short expiry on any link that goes somewhere you do not control, because the cost of a leaked link is measured in how long it stays alive. Put approval on any chat where membership carries value, and accept the queue as the price. Remember that these two are exclusive with a member cap rather than with each other, so a public link can have both an expiry and an approval queue.

Review the list quarterly and clear the dead

Read the link list once a quarter with the per admin view open. Revoke what no longer has a job, delete the revoked entries belonging to people who have left, and check whether one admin is quietly generating links nobody asked for. This is the same fifteen minute habit as reviewing the admin list itself, and the two are best done in the same sitting since one governs who may open doors and the other shows which doors are open. Teams running several accounts across several chats usually reach the point where this needs a place to live, which is the gap our Account Manager fills, and the outreach side of the same problem is what Mass DMs handles.

Frequently Asked Questions

Why does my Telegram invite link say expired

Either the link passed the expiry date set on it, or somebody revoked it, or the address you are using is not the address that was issued. The platform separates these into distinct refusals, and the practical test is whether the link ever worked for anybody: if it did, it expired or was revoked and needs replacing, and if it never did, the address itself is damaged.

Can two admins share the same invite link

No. Each administrator generates their own links, and an admin looking at a link created by somebody else sees it with part of the address hidden. Handovers are done by creating new links rather than passing existing ones along.

What happens if I revoke the main invite link

A new primary link is generated automatically in the same operation, so the chat is never left unreachable. Anybody holding the old address can no longer join, and the record of who joined through it is still available.

Can I set a member limit and require approval on the same link

No, and this is enforced by the platform rather than by the interface. If the approval flag is set, a member limit cannot be specified. Use two separate links if you need both behaviours.

How many people can join through one invite link

Up to ninety nine thousand nine hundred and ninety nine, and the limit counts members who are in the chat at the same time after joining through it rather than total taps. A link with no limit set is unlimited.

Why can somebody not join even though the link works for me

Most often they have hit their own ceiling on how many groups and channels one account may join, which is five hundred by default and one thousand with Premium. The other common cause is that the chat itself is full. Neither has anything to do with your link.

Can I message somebody before approving their join request

Yes, and there is a short window for it. A bot handling the request receives an identifier it can use for five minutes to message the requester before the request is processed, provided no other administrator has already contacted them.

Does Telegram tell me which link each member used

Yes. Every join is recorded against the link that produced it, links can be listed per administrator, and approvals record which admin approved. Naming your links is what turns that record into something readable.

How much can I charge for a paid Telegram channel

Between one and ten thousand Telegram Stars per period, and the only permitted period is thirty days. The ceiling is published in Telegram's client configuration, and prices outside the range are refused when the link is created.

What happens when somebody's paid subscription expires

They leave the channel, and the link keeps a count of members who joined through it and left for that reason. Admins can list expired subscribers specifically. If the person left before their paid period ended, they can re join for the remainder without paying again.

How many chat folder links can I create

Three per folder without Premium and one hundred with it. Separately, a person may join two shared folders without Premium and twenty with it, which is usually the tighter constraint in practice.