Can a Telegram bot invite a user to a channel directly?
No. There is nothing on the Bot API to point at a person.
Telegram words the permission itself carefully. The administrator right involved is can_invite_users, and the Bot API reference defines it as being allowed to invite new users to the chat. Invite, not add. Even unbanChatMember, the one method that sounds like it might put somebody back, states that the user will not return automatically and will only be able to join via a link. Lifting a ban hands back a door, not a seat.
The phrasing of the search barely moves the answer. Telegram bot invite user to channel, telegram bot invite user to group, invite member bot telegram: all of them end at the same object, and that object is a URL sitting in a clipboard, waiting for somebody who was never asked to tap it.
Why the add side carries no method at all we took apart in why an add refusal is rarely about pacing. The rule that stops a bot adding a stranger also stops it messaging one, which is why a mass DM bot cannot open the chat.
Primary links, extra links, and the one that quietly revokes the others
Most people meet this distinction by breaking it.
A chat has one primary invite link and any number of additional ones. exportChatInviteLink generates a new primary link, and the method's own description is blunt about the cost: any previously generated primary link is revoked. Call it a second time because the first response scrolled off the console, and everybody still holding the earlier URL is now holding a dead one. createChatInviteLink is the method that adds a link instead of replacing one, and it is the method almost every real deployment actually wanted.
There is a second surprise underneath that, and it is deliberate rather than a bug. Telegram states that bots cannot use invite links generated by other administrators. The link you created by tapping through the app is therefore invisible to your bot, and editChatInviteLink only edits a non-primary link the bot itself made. Two administrators, two disjoint sets of links, no shared view between them. A bot handed an established channel starts with nothing it is able to manage.
The parameters are where the useful part hides. A link carries an optional name of up to 32 characters, an expire_date, and either a member_limit or a creates_join_request flag. The name is the one nobody writes about, and it is free attribution: one named link per source, and the counts that come back tell you which of your channels is actually recruiting, with no redirect service and no tracking parameter anywhere in the chain. Revoking follows the same logic. revokeChatInviteLink kills a link, and if the one you killed was the primary, a replacement is generated automatically, so a chat is never left without a primary link. It is only ever left with a stale one written down somewhere.
The pattern that survives contact with a real channel is short enough to state in a sentence. Leave the primary link alone, issue a named one for every place you intend to publish it, and treat those names as the only report anybody is going to hand you. Nothing in the 2026 reference does that bookkeeping on your behalf, and nothing in it needs to.
Does the person on the other end have to agree?
Yes, and that is the entire difference between the two products.
A link cannot be aimed. It sits there until a human decides to act on it, which is why Telegram's own privacy machinery treats being added and being invited as a single setting: the privacy key that governs it is described as whether the user can be invited to chats. Somebody who switched that off two years ago has already answered the question, and no client, ours included, gets to re-ask on their behalf.
Being polite in shape does not make bulk distribution polite in practice. The spam FAQ names invite links to groups or channels among the things people do not want unsolicited, and says the same about adding people to unwanted groups. The Terms of Service come down to one line worth keeping in view: do not use the service to send spam or scam users. The reports that follow land on whoever sent the link, which is the same machinery behind another method the Bot API simply does not carry.
The join request queue is the part worth building on
Set creates_join_request on a link and it stops being a door. It becomes an application form.
What arrives is a queue rather than a member. Clearing it needs that same can_invite_users right, through approveChatJoinRequest and declineChatJoinRequest, and the link object reports a pending_join_request_count so the backlog is visible without walking the member list. Channels can go one step further: createChatSubscriptionInviteLink issues a recurring-access link priced in Telegram Stars, with a subscription period the reference fixes at 2592000 seconds. Thirty days, and no other value is accepted.
None of it helps if what you have is a spreadsheet. A queue processes people who came to you, and it has no input for people who did not, which is why how the username list is built in the first place decides so much about what happens next.
Where the link stops and an account starts
Past the link, there is no bot left in the story.
Every route that begins with a list of usernames runs from a signed-in account over MTProto. That is how a telegram invite member bot and a plain member adder end up on one results page while behaving nothing alike. One produces a URL and waits. The other spends an account's standing on every call, and gets refused by recipients far more often than it gets slowed by any limit — which makes it a list problem before it is a speed problem.
Our Member Add and Add Contacts to Group modules sit on that second side, alongside the rest of the group operations in the module list. They spread a list across the session pool, hold a per-account cap, randomise the interval between calls and back off a wait rather than retrying into it. That is pacing, and pacing is all it is.
The honest limits are short. This software exposes no capability the API does not already carry, it does not supply accounts or proxies, it cannot make a link reach anybody who never taps it, and it lifts nothing Telegram enforces on its own servers. Every client that speaks the API meets the same wall we do.
If the link route fits your case, you do not need us for it. The Bot API is free, the invite surface above is the whole of it, and half an afternoon covers the implementation. If the account route is the one you are looking at, what the suite costs to licence covers all 25 modules on a single plan, and asking us whether your case fits is cheaper than discovering it mid-run. Everything else we have taken apart is filed next door.