The Telegram Bot Token: Getting It and Keeping It Safe

The token is the key to the bot. Whoever holds it is the bot: they can read incoming messages, write as it and change its settings. That governs how it is stored.

BotFather, step by step

1. Create the bot with the creation command in the BotFather chat.
2. Set the display name. Users see it, and it can be changed later.
3. Set the username. Unique, ending in bot, and unchangeable. Choose deliberately: a taken username cannot be freed and a bad one is permanent.
4. Receive the token, delivered as a chat message.

A few things worth setting immediately and usually forgotten:

• Description and greeting text. Users see them before the first message, and an empty description reads as an abandoned bot.
• The command list. It appears in the menu and noticeably reduces questions.
• Group privacy mode. By default a bot in a group sees only messages addressed to it. If it must read everything, disable that deliberately; if not, leave it on.
• An avatar. A small thing that affects trust.

Where to store the token

Correct: an environment variable on the server, read at startup.

Also acceptable: a settings file outside the repository, with restricted permissions.

Not acceptable:

• In the code, even temporarily: temporary things live longest.
• In the repository, even a private one. Private repositories become public and members change.
• In messages and tickets. Conversations live long and are widely readable.
• In launch command arguments: they land in shell history and the process list.

The repository should contain an example settings file with variable names and no values. That is both documentation and protection.

What to do on a leak

One action: regenerate the token in BotFather. The old one stops working immediately.

What not to bother with, because it achieves nothing:

• Deleting the message with the token - it may have been copied.
• Deleting the commit - it stays in history and in clones.
• Hoping nobody noticed. Public repositories are scanned automatically and discovered tokens are used within minutes.

After regenerating, update the value everywhere it is used: server, development environment, CI. This is the case where knowing that list in advance pays off.

Bot permissions

The token grants full access, so restrictions are built around it rather than inside it.

A separate bot for testing. Development and production must not share a token, or a test message reaches real users.

Minimal group permissions. If the bot only needs to send messages, it does not need admin rights. Delete and ban rights are granted only when unavoidable.

Administrator checks on your side. The list of who may control the bot lives in your configuration, not in the assumption that an admin button is invisible to others - see buttons.

Webhooks over HTTPS only, with a secret in the path or header - see deployment.

How to find a chat identifier and how it differs from a user identifier: chat id. The overview is in the Telegram bots guide.