Telegram Serverless token rotation: separate Bot API and CLI credentials

When a Telegram credential is exposed, “generate a new token” is an action, not a complete recovery plan. First determine whether the exposed secret authenticates the bot to the Bot API or gives a tool access to its Telegram Serverless application. Those credentials cross different trust boundaries. Replacing one does not automatically invalidate the other.

A defensible rotation closes four gaps: identify the credential, contain its exposure, validate the replacement, and prove the old value no longer works. A code rollback, redeployment, or deleted chat message does not revoke a credential.

Start with two different tokens

Telegram's official bot tutorial defines the Bot API token as the string that authenticates the bot—not the owner's personal account—to the Bot API. It should be protected like a password and can be revoked through Telegram's official BotFather.

BotFatherV2's connection documentation describes a different credential: the Telegram Serverless CLI token. It is generated under Serverless settings in the official BotFather, begins with app, and is separate from the ordinary Bot API token.

Credential	Primary purpose	What an incident responder must not assume
Bot API token	Lets software call the Bot API as the bot	Updating a Serverless connection does not invalidate the old Bot API token
Serverless CLI token	Lets publishing tools connect to the corresponding Serverless app	Redeploying bot code does not revoke the old CLI credential

Do not classify a credential only by where somebody pasted it. Return to the official BotFather settings for the correct bot and confirm its source, purpose, and owner. If a screenshot or log preserves only a fragment and the type cannot be established, track both credentials as separate items to investigate.

Contain exposure before changing values

Stop spreading the secret before asking more people to diagnose it:

• Do not paste either token into AI chat, source files, screenshots, tickets, group chats, or support messages.
• Record discovery time, affected bot, credential type, exposure location, and possible viewers without copying the complete value into the incident record.
• Check whether a generation, import, or publication task is active. Before replacing a Serverless CLI token, let the active task reach a clear terminal state.
• Treat a credential found in a public repository, public chat, or uncontrolled third-party system as compromised. Do not wait for visible abuse.

The OWASP Secrets Management Cheat Sheet recommends recording a secret's purpose, consumers, and lifecycle. It also makes an important operational distinction: restarting an application does not revoke a stolen credential; the backing provider must expire or revoke it.

Rotate a Bot API token safely

Use this sequence when a Bot API token is public or its confidentiality is uncertain:

1. Identify the correct bot in Telegram's official BotFather. Do not rely on a similar username or an old screenshot.
2. Revoke the old Bot API token and generate its replacement. Telegram's tutorial explicitly says a bot token can be revoked through BotFather.
3. Update the replacement only in the secure configuration consumed by the live bot. Do not put it in source code, Markdown examples, or client-side variables.
4. Redeploy or restart the actual runtime that consumes that token.
5. Use an ordinary test account to verify the expected bot identity, private commands, and required group permissions.
6. Perform a negative check against the old token: authentication should fail. Keep the complete value out of browser history, screenshots, and shared terminal output during testing.

Rotation is not complete if nobody can list all credential consumers. Old scripts, CI variables, temporary debugging machines, and personal password managers can all reintroduce a revoked value.

Do not switch a Serverless CLI token mid-publish

BotFatherV2's public documentation gives a specific order: generate the replacement in the official BotFather, wait for active tasks to finish, then reopen the connection settings and update the credential. Do not revoke the old token while publication is in progress.

A testable sequence is:

1. Confirm that the workspace's Telegram username matches the bot selected in the official BotFather.
2. Wait until generation, import, and publication tasks have an explicit terminal state.
3. Generate a replacement under Serverless CLI Access in the official BotFather.
4. Update it in BotFatherV2's connection settings, never in the AI conversation.
5. Require the real read-only cloud connection check to succeed. A network failure is not a verified connection.
6. If cloud code already exists, confirm that the required complete import is satisfied before modifying or publishing it.
7. After a minimal publish and real Telegram test, revoke the old credential during a window with no active task, then confirm that the old value can no longer connect.

A successful connection proves that the replacement can reach the intended application. It does not prove every business path works. Test real commands, permissions, and persistent data. Keep database and business-logic changes out of the credential-rotation operation.

Removing copies is not revocation

Deleting a token from the latest file does not remove it from Git history, pull requests, logs, or caches. GitHub's Push protection blocks recognized hardcoded credentials before they enter a repository. That is a preventive control, not a revocation mechanism for a secret that has already escaped.

Continue cleanup after the provider-side rotation:

• Remove or restrict screenshots, chats, tickets, and build logs containing the value.
• Inspect every branch and historical record, not only the current file.
• Enable suitable secret scanning or push protection and limit who can bypass it.
• Log only credential type, action, result, and a redacted identifier—not the complete secret.
• Record when the old credential was revoked, when the replacement became active, and who performed the work.

Even when a historical copy cannot be erased immediately, provider-side revocation should make the old value unusable. The reverse is not true: deleting copies without revocation can leave an attacker's copy valid.

Acceptance checks for a closed rotation

• The incident identifies the Bot API token, the Serverless CLI token, or both as separate rotation targets.
• The replacement exists only in its intended secure connection or configuration surface.
• Authentication or connection with the old credential fails explicitly.
• The new credential reaches the intended bot and Serverless app, not a similarly named object.
• No in-flight publication was interrupted by the switch.
• Private commands, group permissions, and required data operations passed a real Telegram test.
• Source, Git history, logs, screenshots, AI chats, and support messages were checked for copies.
• The incident record keeps timestamps, owner, and results without preserving the full token.

Rotation is closed only when “the replacement works” and “the old value does not” are both demonstrated.

Where BotFatherV2 fits—and its boundary

BotFatherV2 uses a Serverless CLI token to verify and connect a Telegram Serverless application you own; the normal Bot API token is not the credential requested for this connection. On 22 October 2026, that required /en-US homepage still returned 404, so the currently accessible English homepage is included as a fallback.

BotFatherV2 supports AI-assisted bot creation and modification, version publishing, and code rollback that retains current business data. Version operations do not revoke Telegram credentials. The public Build with AI documentation still says the fixed SDK excludes arbitrary npm modules and Node/Bun runtime APIs, while new paid runtime AI integrations remain outside the first version.

Credential rotation is a connection and operations workflow. It does not imply that generated bots include a secret manager or autonomous agent behavior. BotFatherV2 is an independent product and is not affiliated with Telegram's official BotFather. Create, revoke, and manage Telegram credentials through the official BotFather and current platform documentation.

Sources and verification notes

• BitBear Studio: Connect Telegram and its Chinese counterpart 连接 Telegram; no publication date shown.
• Telegram: From BotFather to 'Hello World', official English tutorial; no publication date shown.
• OWASP: Secrets Management Cheat Sheet, English security guidance; no publication date shown.
• GitHub Docs: Push protection, English product documentation; no publication date shown.

All pages were retrieved on 22 October 2026. This guide turns their separate credential and lifecycle facts into an operational checklist; the retrieval date is not presented as an external publication date.