Telegram join-request bots: approvals, invite links, and acceptance checks

A reading club's admission bot does not necessarily need AI to judge prospective members. The important questions are who decides, which entry paths exist, what failures look like, and whether the bot can verify that an action completed.

Start with Telegram's native administrator review. Consider a custom bot only when you need additional business records or an established review process. The workflow below is a design proposal, not a demonstration of a deployed bot.

A request is not membership

Telegram's November 3, 2021 announcement introduced administrator approval for invite links: people submit requests for administrators to approve or dismiss. This is an established feature, not a newly released capability, and requesting access is different from joining immediately.

Use precise interface labels: “Request submitted,” “Awaiting review,” and “Approval action completed.” Receiving an event is not sufficient reason to say “You have joined.” If the business needs confirmation of current membership, specify that as a separate check rather than inferring it from local records.

Do not rebuild native review without a reason

Ask three questions first:

• Is reviewing requests directly in Telegram already sufficient?
• Do you need business application IDs, reviewer records, or decision explanations?
• Who will handle unreachable applicants, changed rights, and uncertain outcomes?

If native review is enough and the additional requirements are unclear, retain the simpler process. A bot should implement identified business steps, not take over admission just to add an “AI review” label.

Telegram's Invite links documentation covers expiration, revocation, join requests, and administrator handling. It also contains MTProto methods. These describe platform mechanisms, not proof that Telegram Serverless exposes corresponding operations through its fixed SDK. Do not treat those method names as confirmed BotFatherV2 interfaces.

Audit every entrance, not just the bot's link

Shared chat folders are an important exception. Telegram's official Spanish shared-folder guide says folder invitations allow recipients to join included chats directly, even chats that normally require approval. Having an approval bot therefore does not establish that every admission passes through it.

Before release, inventory public entrances, active old invitations, links created by other administrators, and shared folders containing the chat. Record the owner, intended audience, and continued purpose of each entrance. Do not revoke all production invitations as a test; agree on scope with the administrators first.

Define a revocation test as “This entrance no longer accepts new joins,” not “Everyone who previously joined through it has been removed.” Removing existing members is a separate, consequential operation requiring its own authorization and acceptance checks.

Give applications inspectable outcomes

The following are proposed business states, not Telegram's official enum:

1. Awaiting review: retain the necessary application identifier, destination, and applicant identifier. Do not collect identity documents, passwords, or login codes.
2. Decision recorded, execution pending: record the designated reviewer's decision without presenting it as a completed platform action.
3. Action completed: record completion only after a definite execution result. Check current membership separately where required.
4. Needs reconciliation: insufficient rights, timeouts, or another administrator's intervention require investigation, not invented success or endless approval retries.

When the implementation cannot safely establish current state, preserve necessary evidence and return control to Telegram's native administrator interface. Do not regenerate invitations, admit someone automatically, or dismiss other applications merely to clear an error.

Specify visibility too: applicants see their own progress; designated reviewers see necessary records; public groups do not receive personal details or internal rejection explanations. Recheck execution rights after administrator changes instead of trusting the original configuration forever.

An editable requirement example

Design an admission assistant for a reading club, with final decisions made by designated administrators and no model-based automatic approval. First report whether the available SDK can receive requests, verify rights, approve or dismiss, and confirm outcomes. Leave unsupported steps in Telegram's native manual workflow. Store only necessary identifiers and status. If someone already handled the request through another entrance, reconcile current state rather than overwriting the result. Put uncertain actions in a review list; never send an unverified success message. Inventory old invitations and shared-folder entrances before release.

This is a specification example. An applicant's bio, display name, or “I was already approved” message is not an authorization credential. If a model is later used to summarize applications, its output should help reviewers read, not acquire administrative authority.

Test six situations

Use a dedicated test group and fictitious accounts:

• An ordinary application: submission, decision, and execution result remain distinguishable, with no premature membership claim.
• Native review completes first: reconcile the change or request human review instead of blindly applying an opposite decision.
• The bot loses its rights: stop execution, retain pending records, and tell the maintainer what is missing.
• An action times out: report an uncertain outcome, not a rejection inferred from a network failure.
• Old links and shared folders: test actual entry paths so the approval coverage is not overstated.
• An unrelated user inspects or acts on an application: deny access to others' records and administrative decisions.

Also agree on record retention and deletion. Deleting business records must not unexpectedly remove a member or send another invitation.

Applying this with BotFatherV2

BotFatherV2 creates and modifies Telegram bots through AI conversation. Submit the requirement, then determine the feasible scope from generation checks and test-group results. The product also supports importing existing Telegram Serverless bots, publishing versions, and rolling back code while retaining current business data. Rolling back code does not reverse admission decisions already executed.

Public development documentation checked on October 16, 2026 still specifies a fixed SDK without arbitrary npm packages or Node/Bun runtime APIs. The initial release does not add bot runtime features dependent on paid AI. This article does not establish built-in admission management, MTProto clients, shared-folder management, or model-based identity verification. Use native manual review if required events and operations are unavailable. BotFatherV2 is independent of Telegram's official BotFather and is not affiliated with Telegram. For baseline message visibility, see the group privacy and permissions checklist.

Sources and verification date

• Telegram Team, Hyper-Speed Scrolling and Calendar View for Shared Media, Join Requests, Global Chat Themes on iOS and More, published November 3, 2021; accessed October 16, 2026.
• Telegram, Invite links, no explicit publication date shown; accessed October 16, 2026.
• Telegram, Carpetas de chats compartibles, official Spanish guide, feature listing dated April 21, 2023; accessed October 16, 2026.
• Additional product-boundary check: BitBear Studio, Build with AI, accessed October 16, 2026.