Home › Resources

Telegram Bot Privacy Policy: What Telegram Requires and How to Write One

Published October 2, 2026

Telegram requires every bot and Mini App on the platform to have a privacy policy. The Bot Developer Terms of Service (Section 4) state that developers must maintain an accessible privacy policy detailing what data the bot stores, how it collects that data, and what it uses it for. Telegram provides a Standard Privacy Policy for Bots and Mini Apps as a default, but any bot whose data practices go beyond what that template describes -- storing messages, calling third-party APIs, running payments, or collecting data the standard template does not account for -- must register a separate, custom privacy policy through @BotFather.

This guide covers what Telegram actually checks, what data your bot receives through the Bot API that you need to disclose, the additional obligations Mini Apps and payment bots carry, how to handle GDPR and data retention, and a ready-to-copy sample policy you can adapt for your own bot. If you want a finished policy instead of writing one from scratch, generate a privacy policy for free and host it at a permanent URL.

What Telegram Requires and Where the URL Goes in BotFather

Telegram's standard policy applies automatically to every bot that does not register its own. It covers the basics -- the bot only requests data necessary for its features, does not transfer data to third parties beyond what the policy allows, and gives users 30 days to request data copies or deletion. For a simple bot that responds to commands without logging anything, the standard policy may be enough.

Most real-world bots outgrow it. If your bot stores conversation history, calls an external AI API with message content, logs user activity in a database, collects payments, or does anything the standard template does not describe, you need a custom policy. The Developer Terms are explicit: developers whose services conflict with or go beyond the Standard Privacy Policy must provide a separate privacy policy.

To register your custom policy, open a chat with @BotFather on Telegram and use /mybots to select your bot. From the bot's settings, you can set your privacy policy URL directly. Once set, the policy becomes accessible to users through a dedicated button in the bot's profile and in Mini App settings menus. The custom policy takes precedence over Telegram's standard template from that point on.

This is the same pattern other platforms follow: Discord requires a privacy policy URL in the Developer Portal before bot verification at 75 servers, and Google enforces one for every Chrome Web Store listing. The platform gatekeeps distribution behind a policy check, and the policy has to match what the bot actually does.

What Data a Telegram Bot Collects

The gap between what developers think their bot collects and what it actually receives through the Bot API is where most policy mistakes happen. Your bot processes data every time Telegram delivers an Update object, whether or not anything touches a database.

• User identity. Every interaction carries a User object with the sender's numeric id, first_name, optional last_name, optional username, language_code (an IETF tag like en or pt-br), and is_premium flag. The numeric id is a persistent identifier -- personal data under GDPR before you ever write it to disk.
• Chat identifiers. The Chat object includes the chat id, type (private, group, supergroup, or channel), and for private chats the user's first_name, last_name, and username again. Group and supergroup chats expose the group's title.
• Message content. In private chats and when the bot has privacy mode disabled in groups (controlled via /setprivacy in BotFather), every message's full text, attached media, forwarded-from metadata, and reply chain land in your Update handler. With privacy mode enabled -- the default -- the bot only sees messages that mention it by @username, replies to its own messages, and slash commands.
• Inline queries. When a user types @yourbot followed by a search term in any chat, your bot receives an InlineQuery object containing the sender's User data and the query string they typed -- even though the bot is not a member of that chat.
• Callback data. Tapping an inline keyboard button sends a CallbackQuery with the user's identity and the data string you encoded into the button. If your buttons carry user-specific payloads, that is personal data in transit.
• Location. Bots that request location (via KeyboardButton with request_location, or inline bots with /setinlinegeo enabled) receive the user's latitude and longitude -- sensitive data that many policies forget to disclose.
• Shared contacts. A user can share a phone contact through the request_contact keyboard button, handing the bot a phone number and name -- data that goes well beyond the default Bot API surface.

The takeaway: even a stateless bot that stores nothing still processes user IDs and message content in memory. "We do not store data" is a valid disclosure, but only after you account for what the Bot API delivers to your code on every event. The same principle applies to writing a privacy policy for any app -- audit what you actually receive, not just what you save.

Mini Apps and Payments

Mini Apps (formerly Web Apps) and payment-enabled bots handle data beyond the standard Bot API surface, and the privacy policy needs to cover both.

Mini App data

A Mini App runs inside Telegram's in-app browser and receives initialization data through window.Telegram.WebApp.initData. This signed payload includes the user's id, first_name, last_name, username, language_code, and is_premium status, plus the chat_instance identifier and any start_param passed in the launch URL. If the Mini App makes its own network requests -- to your backend, to an analytics service, to a third-party API -- each of those is a data flow the policy must name.

Once a developer sets a custom privacy policy through BotFather, users can access it via a dedicated button in the Mini App's settings menu. That is where users go to check what your Mini App does with their data, so the policy needs to describe the Mini App's practices specifically, not just the bot's slash-command behavior.

Payment data

Bots that accept payments through Telegram's built-in payment system (using the sendInvoice method and a connected payment provider) receive a PreCheckoutQuery and, after a successful payment, a Message with a successful_payment field containing the currency, total_amount, invoice_payload, and order_info (which may include the buyer's name, phone, email, and shipping address). The Developer Terms require that bots handling Telegram Business transactions "clearly state what private user data you will retain, how long you will store it" and not disclose message contents to third parties without authorization.

Your policy must name the payment provider, specify which order fields you store (and which the provider stores on its own), and set a retention period for transaction records -- keeping them indefinitely with no stated reason is the kind of gap that surfaces in audits.

GDPR Legal Basis and Data Retention

Telegram is used globally, so most bots have at least some EU or UK users, putting GDPR in play. The two legal bases that apply to most bots are:

• Legitimate interest (Article 6(1)(f)) -- processing the user's id, username, and command input to deliver the bot's core function. This covers the basic command-response loop: the user sends a command, the bot processes it, the result comes back.
• Consent (Article 6(1)(a)) -- any processing that goes beyond delivering the requested feature: analytics tracking, sharing data with a third-party AI service, marketing messages, or storing message history for purposes the user did not initiate. Consent must be freely given, specific, and revocable.

For retention, Telegram's Developer Terms require developers to delete user data when the user requests it, when retention is no longer necessary for the service, and when the service ceases operation (unless users explicitly consent otherwise). Your policy should state concrete retention periods rather than "as long as necessary." A moderation bot that keeps warning records for 90 days and purges them automatically is a clearer disclosure than one that keeps records indefinitely "for safety."

The Developer Terms also prohibit data collection for building datasets, machine learning models, or AI products through scraping -- that restriction applies regardless of legal basis and should be acknowledged in the policy if your bot processes group or channel content.

What Your Bot's Privacy Policy Must Include

Name the bot specifically -- a generic policy that never identifies the bot it covers is the privacy-policy equivalent of a placeholder page. Beyond that, cover these sections:

• What data you collect. List the Bot API objects and fields your bot processes: User.id, User.username, Message text, InlineQuery.query, location, contacts, payment details -- whatever applies.
• Why you collect it. Tie each data type to a feature. If your bot stores User.id for per-user settings, say that. If it reads message content for moderation, say that.
• Third parties. Name your hosting provider, database service, payment provider, and any AI API your bot calls with user data. The Developer Terms bar transferring data to third parties except as the policy describes.
• Retention periods. Real numbers: "message logs, 30 days; user preferences, until the user deletes them or the bot is removed from the chat." State what happens to stored data when the bot is removed from a group or blocked by a user.
• User rights. How someone requests a data copy or deletion. Telegram's standard policy gives users 30 days for a response -- match or beat that timeline.
• Children. Telegram's minimum age is 16 in the EU and 13 elsewhere. State that the bot is not directed at users below the applicable minimum age.
• Contact and updates. A working email or Telegram contact, and how policy changes are announced.

Sample Telegram Bot Privacy Policy

A template for a bot called "[Your Bot Name]." Copy it, fill in the bracketed fields, and delete any section that does not apply to your bot.

Bots with Mini App features or complex third-party integrations need additional sections for each data flow. Want a policy built from your bot's actual data practices instead of editing a template? Build one for free with the generator and get a hosted URL you can paste straight into BotFather.

Hosting Your Policy and Linking It

The policy URL needs to resolve over HTTPS and load without authentication. Telegram does not prescribe where you host it, but the URL must be publicly accessible since it is displayed to users directly from the bot's profile and Mini App settings.

• Your bot's website — a path like yourbotname.com/privacy. Gives you full control over content and uptime.
• A free generated policy — if you do not have a website, generate and host a policy at no cost and use the permanent URL it gives you.
• GitHub Pages — a static HTML file in a public repo, common for open-source bots, as long as it loads without a GitHub login.

Avoid Google Docs, Notion pages, or Pastebin links -- they can change privacy settings, move behind authentication, or disappear entirely. Once you have the URL, open @BotFather, run /mybots, select your bot, and set the privacy policy link in the bot's settings. The URL appears immediately on your bot's profile and in Mini App menus.

Frequently Asked Questions