How to Get a Telegram Bot Token from BotFather (and Keep It Safe)

To get a Telegram bot token, open a chat with @BotFather, send /newbot, give the bot a display name, then a username that ends in "bot". BotFather replies immediately with the token, a string shaped like 110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw. That string is the bot's only credential: whoever holds it controls the bot.

Last verified: November 2026 against Telegram's BotFather documentation and the Bot API reference.

The full sequence, start to finish:

1. In any Telegram app, search for @BotFather and open the account with the blue verification check. t.me/BotFather opens it directly. Impersonator accounts with similar names exist, and they collect tokens.
2. Tap Start (or send /start) to see the command list.
3. Send /newbot.
4. When asked for a name, send the display name users will see in chats, for example Acme Support.
5. When asked for a username, send a unique handle ending in bot, for example acme_support_bot.
6. BotFather confirms with a message containing your bot's t.me link and the HTTP API token. Copy the token into a secret store right away, not into a notes app or a chat with a colleague.

Telegram also ships a BotFather Mini App with the same functions in a graphical interface. The commands below work in both, and the docs describe the chat commands as the reference.

BotFather asks for two identifiers that look interchangeable and are not. The display name is cosmetic and editable. The username is permanent.

Two rejections come up constantly at this step. The username is taken: usernames are global across Telegram, so short generic names are long gone, and adding your brand plus a function (acme_orders_bot) usually works. It does not end in "bot": the suffix is mandatory, in any case (tetris_bot and TetrisBot are both valid, per the docs).

Because the username lives in every link you print, every QR code and every /command@username in a group, treat it like a domain name. If you need a test bot, create a second bot with a second username rather than renaming the production one later, which you cannot do anyway.

A token has two halves separated by a colon:

110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw
|_______| |__________________________________|
 numeric        secret part
 bot ID

The part before the colon is numeric and identifies the bot; you will see the same number as the id field when you call getMe, which makes it a handy way to tell two bots' tokens apart without exposing the secret. The part after the colon is the secret. People sometimes call the whole string a "Telegram bot API key"; there is no separate API key, API secret or client ID for the Bot API. This token is all of it.

Every Bot API call puts the token in the URL path, prefixed with the literal word bot:

https://api.telegram.org/bot<TOKEN>/METHOD_NAME
https://api.telegram.org/bot110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw/getMe

The docs call this out explicitly ("remember to prefix the word 'bot' to your token"), and it is still the most common copy-paste error. The two failure signatures are distinct:

Libraries such as python-telegram-bot, aiogram, grammY and Telegraf add the prefix for you, so pass them the bare token. Passing bot123:ABC to a library produces botbot123:ABC in the URL and a 401 or 404 that looks baffling until you log the request path.

Lost the original message? You do not need to create a new bot. BotFather keeps the token available to the bot's owner:

1. Send /mybots to @BotFather.
2. Tap the bot in the list.
3. Tap API Token. BotFather shows the current token.

Only the Telegram account that owns the bot can do this. If the bot was created by a former employee or an agency, the owner must either send you the token or use BotFather's ownership transfer (/mybots, select the bot, transfer ownership). Telegram's docs note two constraints: the recipient must have interacted with the bot at least once, and the transfer is permanent and hands over full control, including deleting the bot.

Transfer is the right fix for an orphaned business bot. Asking the old owner to paste the token in Slack leaves a live credential in a chat log forever and leaves them able to regenerate it at any time, which silently breaks your integration.

getMe is documented as "a simple method for testing your bot's authentication token". It needs no parameters:

curl -s https://api.telegram.org/bot<TOKEN>/getMe

A valid token returns the bot's own profile:

{
  "ok": true,
  "result": {
    "id": 110201543,
    "is_bot": true,
    "first_name": "Acme Support",
    "username": "acme_support_bot",
    "can_join_groups": true,
    "can_read_all_group_messages": false,
    "supports_inline_queries": false
  }
}

Three fields here are only returned by getMe and answer questions people usually debug the hard way:

• can_read_all_group_messages is true only if privacy mode is disabled. If it is false, your bot will not see ordinary group chatter, which is the default and usually correct.
• can_join_groups reflects the /setjoingroups toggle. If it is false, nobody can add the bot to a group.
• supports_inline_queries reflects /setinline.

Check that username is the bot you expect. Teams with a staging bot and a production bot regularly ship the wrong token, and both pass getMe. If you would rather not use a terminal, the Telegram bot token checker runs getMe and getWebhookInfo from your browser and explains the result.

If a token leaks, regenerate it. Telegram's docs name the command: "If your existing token is compromised or you lost it for some reason, use the /token command to generate a new one." BotFather asks which bot, then replies with a fresh token. In the /mybots menu, the API Token screen offers the same action as a button. Older tutorials refer to a /revoke command; Telegram's documentation says the live command list in BotFather (type / in the chat) is the authoritative reference, so use whichever your client shows.

What happens next matters more than the command:

• The old token stops authenticating. Every process still using it starts receiving 401 Unauthorized. There is no grace period to plan around, so have the new value ready to deploy before you regenerate.
• The bot keeps its identity. Same username, same numeric ID, same chats and subscribers. Only the secret half of the token changes.
• Update every consumer. Production, workers, cron jobs, CI secrets, any third-party platform the token was pasted into. A single forgotten worker using the old token will log 401s that are easy to mistake for an outage.
• Re-check delivery. After deploying, call getWebhookInfo and confirm the url and pending_update_count look right, or run the Telegram webhook checker.

Regenerate on a schedule only if you have automated the rollout. Regenerating by hand "for hygiene" is a reliable way to take a working bot offline at 5 p.m. on a Friday.

One special case: if you build a manager bot with Bot Management Mode, the Bot API exposes getManagedBotToken to fetch a managed bot's token and replaceManagedBotToken to revoke it and generate a new one, so rotation can be automated without BotFather.

Telegram's own tutorial says to "treat it like a password" and suggests a settings file or environment variables rather than source code. In practice that means:

The token sits in the URL path of every API call, which creates a leak path people miss: request logs. HTTP client debug logging, reverse proxy access logs, APM tools and error trackers that capture outbound URLs will all record /bot<TOKEN>/sendMessage unless you redact it. Grep your log pipeline for api.telegram.org/bot once and add a scrubbing rule.

Two related secrets are worth setting up at the same time:

• Webhook secret. setWebhook accepts a secret_token (1-256 characters, A-Z, a-z, 0-9, _ and -). Telegram then sends it in the X-Telegram-Bot-Api-Secret-Token header on every update, so your endpoint can reject requests that did not come from your webhook. Do not reuse the bot token for this value.
• A separate test bot. The docs recommend testing on a different bot account with its own token, so development traffic never touches production users or credentials.

Before trusting any third-party bot platform or browser tool with a production token, check what it does with it: whether calls go straight from your browser to Telegram, or whether the token is stored server-side. When in doubt, test with a throwaway bot.

A Telegram bot token is not scoped. There are no read-only tokens and no per-method permissions: the holder can send messages as your bot to every user who started it, read every update, change the webhook to their own server, and edit the bot's commands and profile. That makes the list of mistakes short and absolute:

• Do not paste it in public. GitHub issues, Stack Overflow questions, Discord help channels, screen recordings and screenshots of BotFather all leak tokens. Replace it with <TOKEN> before sharing anything.
• Do not commit it. Removing the line in a later commit does not remove it from history. If a token was ever committed to a shared repo, regenerate it.
• Do not embed it in client code. A website that calls api.telegram.org from JavaScript, or a mobile app with the token in its bundle, hands the bot to anyone who opens developer tools.
• Do not share one token across environments. One token, one deployment. Two processes polling the same token produce the 409 conflict, and a dev laptop running the production token will steal its updates.
• Do not send it to contractors. Add them to the code, not the credential, or transfer ownership deliberately.

If you suspect a leak, the response is the same every time: run /token, deploy the new value, call getWebhookInfo to confirm the webhook still points to your server and not someone else's, and review getMyCommands in case the bot's menu was changed.

With a working token, the bot still receives nothing until you pick one of the two update delivery methods. They are mutually exclusive: the docs state you cannot receive updates with getUpdates while an outgoing webhook is set.

A minimal first test with polling needs nothing but the token:

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates?timeout=30"

Send your bot a message from your phone and the update appears in the response, including chat.id, which you need for sendMessage. From there:

• Generate shareable t.me links with a start payload using the Telegram link generator.
• Check message sizes, polling and webhook ceilings on the Telegram limits page before you design around them.
• If the bot connects but stays silent, work through why a Telegram bot is not responding, which starts from getWebhookInfo.
• Look up any error string you hit in the Telegram Bot API error codes guide.

If you would rather not run the webhook server at all, a hosted platform can take the token and handle delivery for you; Conferbot's Telegram integration works that way, with the conversation built in a visual editor. Either way, the token you just created is the only thing that ties the bot to you, so the storage rules above apply regardless of who runs the code.