A registration bot asks for a phone number and receives a contact card. Does that establish that the number belongs to the person registering? What should happen if the card has no Telegram user identifier?
Receiving a contact, associating it with a participant, and establishing that a number is currently usable are different outcomes. Decide which one you need before labeling them all “phone verified.”
Request the user's own contact, not any contact card
Telegram's phone-request button documentation describes a reply-keyboard button for private chats: the client must ask permission before sending the current user's contact. This is a client-protocol reference, not a BotFatherV2 endpoint to call directly.
At the Bot API framework level, python-telegram-bot's KeyboardButton reference documents request_contact as sending the user's phone number when pressed, in private chats only. An ordinary text button labeled “Share phone number” does not set that request type.
If an event needs the participant's own contact number, ask for an explicit self-sharing entry point in a private chat. “Accept any contact” is a different requirement. A group can explain how to register, but a private-chat-only button should not become an in-group phone-collection workflow.
Distinguish the contact from the sender
The Contact reference describes a phone number and first name, with optional fields including user_id, last name, and vCard data. That user ID identifies the contact's Telegram user, not necessarily the person sending the message. It is not present on every card.
The following is a recommended registration policy, not a platform identity-verification guarantee:
- Handle contacts only in the current user's private registration step. An unsolicited contact must not silently enter the registration database.
- If the contact includes a user ID, compare it with the sender's user identifier. A mismatch must not attach somebody else's card as the participant's own number; explain how to use the self-sharing entry point.
- If the ID is absent, do not infer ownership from a matching name or plausible phone format. Ask for another share, or follow an explicitly defined manual-review route with an unconfirmed status.
- Even a match only establishes that this workflow's association check passed. Do not turn it into proof of legal identity, continuing number ownership, telephone reachability, or SMS verification.
If registering on behalf of someone else is allowed, give it a separate contact policy. Do not weaken the self-sharing flow while continuing to display “your identity verified.”
Decide whether a phone number is needed before storing it
A local board-game event that sends meeting reminders through Telegram may not need phone numbers at all. If organizers need telephone contact on the event day, explain the purpose, whether sharing is optional, who can view the data, and when it will be cleared before requesting it.
Use the registration ID and Telegram user identifier to associate records. Avoid treating the phone number as the sole record owner or account authorization key. Keep only the fields the workflow needs; receiving vCard data is not a reason to copy it wholesale into storage.
Confirmation messages and public attendee lists should not expose complete numbers by default. Debugging logs should not capture entire contact cards either. When rejecting a suspicious input, explain the next step without echoing another person's full number.
Stopping collection, removing a keyboard, and clearing stored data are separate actions. You can initially specify an organizer-run cleanup process after the event. Automatic expiry needs a separate check of scheduling and storage support. Clearing a bot's saved fields must not be described as deleting every Telegram message or backup. These are data-handling recommendations, not claims about ready-made product cleanup features.
Test six inputs, not just the sharing button
- The participant uses the self-sharing entry point in the private registration step: only their own record changes, and the receipt does not expose the complete number.
- A card identifies a different Telegram user: it is not bound as the participant's own contact, and rejection feedback does not reveal the other number.
- A contact lacks
user_id: the bot requests another share or follows the defined review path, without a verified label. - The user sends a plausible number as text or a matching name: neither bypasses the association policy.
- A contact arrives in a group, outside registration, or after cancellation: it is not collected unexpectedly and does not overwrite a confirmed registration.
- The user declines to share: the bot follows the stated optional-or-required policy, rather than silently filling the number from another input.
These cases test input meaning and collection scope. They do not require AI to interpret a contact or guess who owns a number.
A requirements prompt for BotFatherV2
You can ask BotFatherV2:
Build an event-registration bot with an optional phone number, used only for event-day contact. Offer self-contact sharing, skip, and cancel inside the user's private registration step. Compare the contact's user identifier with the sender's. Reject a mismatch and request another share if the ID is missing; do not infer ownership from names or number formatting. Do not claim legal-identity, SMS, or reachability verification. Do not store unused vCard data or expose complete numbers in receipts and logs. First verify that the current Telegram Serverless SDK supports the request button and incoming fields, then implement and test the six cases above. If unsupported, explain the limitation instead of silently accepting arbitrary cards.
Public product information checked on October 19, 2026 supports conversational bot creation and modification, importing existing Telegram Serverless bots, publishing versions, and rolling code back while retaining current business data. The AI development documentation limits the fixed SDK surface: arbitrary npm modules and Node/Bun runtime APIs are unavailable, and the first release does not add bot runtime features dependent on paid AI.
The Python framework and client-protocol references verify input semantics. They do not establish that BotFatherV2 integrates those frameworks or that the current SDK exposes every relevant field. AI-assisted development also does not imply an autonomous runtime agent. BotFatherV2 is independently operated and is not affiliated with Telegram's official BotFather.
Sources and dates
- Telegram: keyboardButtonRequestPhone, English client-protocol documentation.
- python-telegram-bot project: KeyboardButton and Contact, English framework references displaying v22.8 when checked.
All sources were checked on October 19, 2026. The pages do not establish first-publication dates; a documentation version is not a publication date. The registration policy, requirements prompt, and acceptance cases are original editorial guidance, not a complete business workflow prescribed by these references.