Design a Telegram file-collection bot: identifiers, limits, and acceptance checks

“Let users send files to the bot” can mean three different things: register an attachment, pass it to an authorized reviewer, or download and interpret its contents. Each needs a different permission, storage, and failure policy. Choose the workflow before treating an incoming message as a completed submission.

This guide uses private-chat event submissions as an example. Its requirements and acceptance checks are design proposals, not a tested ready-made bot or a promise that BotFatherV2 supports every file-processing tool.

Receiving an attachment is not receiving its contents

grammY's File Handling explains that incoming updates normally provide file identifiers. Obtaining the bytes is a separate operation. Download links are temporary rather than permanent attachment URLs.

Keep these objects separate:

One file may have multiple file_id values. An identifier obtained by another bot is not a reliable substitute for one obtained by yours. Copying a file-ID column does not prove attachments have migrated successfully.

Download URLs may contain the bot token. Keep them out of replies, public exports, support screenshots, and logs.

Define a file policy before accepting uploads

For each submission type, specify:

• Purpose: registration and forwarding, or content processing?
• Allowed types: photos, PDFs, audio, and explicitly rejected formats.
• Business limits: attachment count and size, including the response to excess.
• Completion: one message, or an explicit confirmation after several uploads?

A Telegram client accepting a file does not prove the bot can download or parse it. Transport limits depend on the method, cloud versus local Bot API, and the hosting environment. Check the actual path rather than inferring bot capacity from a subscriber's upload allowance. General grammY deployment options are not Telegram Serverless settings.

A smaller business limit is reasonable, but label it as your policy. Unknown sizes and unsupported types need a clear response, not an immediate “completed” message.

Test registration, forwarding, and interpretation separately

Start with a narrow workflow: save a submission record and bot-local attachment identifiers, then allow authorized reviewers to access the attachment inside Telegram. Add downloading and interpretation only if extracting text or reading tables is genuinely necessary.

Filenames, extensions, and user descriptions are not trustworthy content validation. A later parser needs separate checks for format validation, malicious files, execution isolation, timeouts, and third-party data handling. Uploaded material must not become executable bot code.

Multiple attachments also need a completion boundary. A user may send several messages; a brief pause does not prove the set is complete. A simple design can offer /finish and /cancel and show an attachment list before confirmation.

A requirement example

Build an event-submission bot for private chats. Users select an event and upload photos or PDFs. Allow at most three attachments and apply a business limit of 10 MB per file; report that the size cannot be confirmed when it is unknown. This version only registers attachments and makes them available to authorized reviewers: no OCR, AI summaries, or file execution. Store the submission ID, submitter, event, attachment identifiers, and review status, never public download URLs. /finish shows the list and asks for confirmation; only confirmation marks the submission complete. /cancel removes the unsubmitted draft. Users can view only their own submissions, and reviewer authorization is checked on every access. Provide withdrawal, explaining that it removes this system's records but does not guarantee deletion of copies already sent in Telegram.

The limit, count, and commands are illustrative. Adapt them to the supported SDK, storage, and transport, and define retention, export permissions, and deletion verification.

Acceptance checks after publishing

1. Send a valid PDF, photo, unsupported format, and oversized attachment.
2. Exercise unknown-size and malformed-file cases.
3. Send attachments in separate messages; nothing completes before /finish.
4. Cancel and restart without carrying old attachments forward.
5. Have two users query each other's submission IDs; access must fail.
6. Remove reviewer privileges and confirm attachment access stops.
7. Resend a registered attachment with the same bot to verify its identifier works.
8. Inspect withdrawal results and logs for tokens, download URLs, and unnecessary content.

BotFatherV2 uses AI conversations to create and modify Telegram Serverless bots. These requirements still need checking against the fixed SDK's attachment methods, persistent storage, and size limits, followed by real Telegram testing. Current public documentation excludes arbitrary npm modules and Node/Bun APIs and does not add paid-AI runtime capabilities in the first release. grammY is a source explaining file behavior, not a package or download plugin promised by BotFatherV2.

BotFatherV2 is independent and not affiliated with Telegram's official BotFather. For the state of a multi-message collection flow, see the multi-step bot guide.

Sources and verification date

• grammY, File Handling, first-party English technical documentation; no explicit publication date shown; checked October 14, 2026.
• Product boundaries were also checked against BotFatherV2's public AI-development documentation that day. Downloading, parsing, and external-storage integrations are not claimed as available platform features.