Asking someone to type @username is a fragile way to choose a person, group, or channel. Usernames are optional and can change; copied names can contain mistakes; two similarly named chats are easy to confuse. Telegram request buttons can let the person choose from an eligible list and return structured user or chat information to the bot.
That improves input quality, but it does not answer every authorization question. A selection proves which item was chosen for this request. It does not prove that the selected user consented to messages, that the bot still has access to the chat, or that a previous administrator decision is still valid.
Choose a user request or a chat request
The python-telegram-bot reference for KeyboardButtonRequestUsers describes filters for regular users or bots, Premium status, and a maximum of one to ten selections. It can also request names, usernames, and photos.
KeyboardButtonRequestChat starts with a required choice between a channel and a group or supergroup. Optional filters cover forum status, username availability, whether the requester created the chat, required administrator rights, and whether the bot is already a member.
| Selection | Useful for | Do not infer |
|---|---|---|
| User request | Selecting an assignee, moderator candidate, or participant record | Permission to contact, subscribe, or act as that user |
| Chat request | Selecting a destination group, forum, or channel for a configured workflow | Permanent membership, current rights, or approval to publish |
Define one purpose per button. “Choose a notification destination” is easier to review than a generic “Choose chat” button reused for publishing, exporting, and moderation.
Use request IDs to correlate the response
Both request objects include a signed 32-bit request_id, which must be unique within the message. The same value returns in the corresponding shared response. This is a correlation identifier for the button interaction—not the selected user's or chat's identity.
Give each button in one message a distinct request ID and store what that request meant: expected selection type, requesting user, workflow record, creation time, and expiration. When a response arrives, reject an unknown, expired, already-used, or wrong-owner request instead of attaching it to whichever setup session is currently open.
Do not use one global “latest request” value. Two administrators configuring different groups at the same time must not overwrite each other's destination.
Store stable IDs separately from display fields
The UsersShared response contains the request ID and a sequence of shared users. The ChatShared response contains the request ID, chat ID, and optional title, username, and photo when those fields were requested.
Use the returned user or chat ID as the identity key. Keep names, titles, usernames, and photos as optional display snapshots. They may be absent or change later, so they must not replace the stable ID in ownership rules, deduplication, or routing.
Chat IDs can exceed a signed 32-bit range; the referenced documentation recommends storage that safely handles signed 64-bit values. Avoid converting identifiers through a narrow database column or a client-side format that can silently lose precision.
Ask for only the fields the workflow needs
A task-assignment flow may need an identifier and display name, but not a profile photo. A destination picker may need a title for confirmation, but not a public username. Set optional requests deliberately and tell the requester what will be saved.
Minimize retention too. If a title or photo is used only for a one-time confirmation screen, decide whether it needs to remain in business storage. Do not copy selection payloads into group logs or support tickets by default.
The person pressing the button chose to share information with the bot for this interaction. That action is not blanket marketing consent from the selected person and not permission to expose the result to other chats.
Recheck authority before the business action
Filters make the picker more relevant, but they are not a permanent authorization cache. Between selection and execution, a user can lose administrator rights, a bot can be removed, or the selected chat can be replaced in the workflow.
Before a consequential action, verify what the current interface can actually verify: the requester still owns the setup session, the saved request is unused, the selected identity matches the intended record, and required current access is present. If the fixed SDK cannot verify a right or use the selection update, stop at a clear manual-confirmation step rather than claiming automatic setup succeeded.
For broadcasts or publishing, add an explicit confirmation that shows the selected destination and requested action. A successful selection alone must not send a message.
A requirement you can give to AI
Build a private setup flow for a community helper. The maintainer can choose either one regular user as a moderator candidate or one group/supergroup as a workflow destination. Use separate request buttons and unique request IDs tied to the maintainer and setup record. Save stable user/chat IDs; use requested names, usernames, or titles only for confirmation. Reject unknown, expired, repeated, cross-user, or wrong-type responses. Selecting a user never opts that person into messages. Selecting a chat never publishes automatically. Before saving the destination, recheck every current membership or administrator condition supported by the SDK and ask the maintainer to confirm. If request-user/request-chat updates are unavailable in the current fixed SDK, report that limitation and fall back to a clearly labeled manual verification flow.
Keep the first version focused on selection and confirmation. Add scheduled work, broadcasts, or external services only after their separate support and authorization rules are verified.
Acceptance checks after publishing
- Two request buttons in one message have different request IDs and map to the correct actions.
- Two maintainers can run setup concurrently without crossing users, chats, or workflow records.
- An expired or replayed shared response changes no data.
- A user request cannot satisfy a pending chat request, and vice versa.
- A username or title change does not create a second identity record.
- A large chat ID survives storage and retrieval unchanged.
- Optional name, username, title, and photo fields can be absent without breaking the workflow.
- Losing required access between selection and confirmation produces a reviewable failure, not a false success.
- Selecting a person sends no unsolicited message; selecting a chat sends no unconfirmed post.
These are proposed tests for a test bot and controlled chats. They are not evidence that a generated bot has already passed them.
Where BotFatherV2 fits—and its boundary
BotFatherV2 helps create and modify Telegram Serverless bots through an AI conversation. On 23 October 2026, that required /en-US homepage still returned 404, so the accessible English homepage is included as a fallback.
Put the selection type, correlation rules, stored fields, authorization checks, and failure behavior into the requirement card before generating a version. The public Build with AI documentation states that the validator uses a fixed SDK surface without arbitrary npm modules or Node/Bun runtime APIs. The framework references in this guide describe Telegram data semantics; they do not mean those packages are installed or that the current SDK supports every field.
AI-assisted development also does not give the deployed bot autonomous agent behavior. BotFatherV2 is an independent product and is not affiliated with Telegram's official BotFather. Review the generated source and validation report, then test the actual selection update and current permissions in Telegram after publishing.
Sources and verification notes
- python-telegram-bot project: KeyboardButtonRequestUsers, v22.8 English reference; no page publication date shown.
- python-telegram-bot project: KeyboardButtonRequestChat, v22.8 English reference; no page publication date shown.
- python-telegram-bot project: UsersShared, v22.8 English reference; no page publication date shown.
- python-telegram-bot project: ChatShared, v22.8 English reference; no page publication date shown.
All four pages were checked on 23 October 2026. This article turns their type definitions into an original setup, authorization, data-minimization, and acceptance checklist. It does not present the access date as a feature release date.