Telegram Test Server: Testing Bots Without Real Accounts

You do not need a pile of throwaway accounts to test a Telegram bot. Telegram runs a separate test environment, usually called the Telegram test server, and the official apps can log into it. It has its own user accounts, its own bots from BotFather, its own Bot API endpoint and its own data, none of which touches the production side where your real users live.

This is the same reflex that pays off elsewhere: reach for the platform’s sanctioned route before you start inventing accounts. On GitHub that means a GitHub App or a documented machine user rather than extra personal logins. Telegram publishes a test route too, so start there.

The test-environment mechanics below come from Telegram’s own documentation, linked at each point and rechecked on 29 October 2026.

What the Telegram test server is

A separate environment with its own accounts, bots and data

Telegram’s bot documentation is blunt about the split: because the test environment is completely separate from the main one, you have to create a fresh user account and a fresh bot inside it. Your production account does not appear there, and your production bot is not the bot you talk to there. Chats, channels, uploaded files and usernames from the main environment are absent.

That separation is the point. You can delete a chat, feed your own bot malformed updates, revoke a token or wipe a group, and nobody who uses your real bot notices.

Who it is for: bot, Mini App and client developers

Three groups get real value out of it:

• Bot developers who want somewhere to break things, including a second user account to talk to the bot from.
• Mini App developers who need a live Telegram client to open a web app from, and who would rather not provision TLS for a service running on a laptop.
• Client developers building on MTProto, who need accounts to run authorization flows against without consuming a real number’s login attempts.

What it isn’t: a place for real users or private data

The test environment is not a private sandbox. Telegram’s authorization documentation warns against storing important or private information in the messages of such test accounts, for two stated reasons: anyone can use the simplified authorization mechanism, and Telegram periodically wipes everything stored there.

Read that literally. Use synthetic payloads and fixture files: no customer records, no production secrets, no credentials you would mind a stranger reading.

Telegram test server login: create a test account

The entry points are hidden behind a deliberate gesture, which is why a Telegram test server login looks impossible until somebody shows you the trick. Telegram documents three clients.

iOS: tap Settings 10 times, then Accounts and the Test option

Tap the Settings icon ten times to reveal the debug option. Then open Accounts, choose the option to log in to another account, and select Test. From there you sign in with a phone number, and the account you create exists only in the test environment.

Telegram Desktop: Shift + Alt + right-click Add Account

Open Settings, hold Shift and Alt together, and right-click Add Account. A menu appears with a Test Server entry. Choosing it starts a normal login flow that lands in the test environment instead of production. That is the whole Telegram Desktop test server gesture, and it is easy to miss because the entry appears only while both modifier keys are held.

macOS: click Settings 10 times, then Command-click Add Account

Click the Settings icon ten times to open the Debug Menu. Then hold Command and click Add Account, and log in with your phone number.

Other apps: only what Telegram’s docs list

Telegram documents iOS, Telegram Desktop and macOS. Android steps are not among them, and neither is any statement about how Telegram Premium behaves on the test side, so this guide does not invent either. If your platform is not covered, use one of the three documented clients for the login and point your own build at the Test DCs through the API.

Telegram test phone numbers for client developers

If you are writing a client rather than a bot, you can register directly against the Test DCs using reserved numbers. Telegram’s user authorization page documents the scheme.

The 99966XYYYY format and the data center digit

The documentation puts X in the range 1 to 3, because only three Test DCs exist. Anything outside that range has no data center to land on.

The login code: the DC digit repeated five times

A test user registered on DC number X always receives the same code: that digit repeated five times. A number on DC 2 takes 22222, which is exactly what you want in a test that runs on every commit.

Test DC addresses from my.telegram.org after you get an api_id

Telegram does not publish the Test DC addresses in the open. They appear in the API development tools panel at my.telegram.org once you have requested an api_id and api_hash. Note the related constraint from Telegram’s page on obtaining an api_id: for the moment each number can only have one api_id connected to it, so plan your credentials around the number you actually control.

Telegram points to the reserved prefixes as the way to check that your app handles data center redirects correctly, which is a flow better rehearsed here than on a real number. Telegram’s data center page documents the migration errors a request can come back with, PHONE_MIGRATE and NETWORK_MIGRATE among them.

Why they exist: login attempts are limited

Telegram caps how many login attempts each phone number gets per day. The documentation names five as an example and says the figure is subject to change, so handle the FLOOD error rather than code a count. When a test number reaches the cap, Telegram’s advice is to pick another by changing the trailing digits.

That cap is the stated reason to get the authorization flow working on Test DCs first and only then run it against production.

This is a testing allowance, not a shortcut around production limits. It only works on Test DCs, and the accounts it creates exist nowhere else.

Testing bots in the Telegram test environment

Create a new bot with BotFather inside the test environment

Once your client is logged into the test environment, open BotFather from that account and create a bot as usual. You get a token that belongs to the test side; the bot you run on production is irrelevant here.

Call the Bot API at the /test/ path

Requests go to the normal host with one extra path segment. Instead of calling a method directly after the token, you insert test:

https://api.telegram.org/bot<token>/test/METHOD_NAME

The documented difference is that one extra path segment, so a library that lets you configure the API base URL can be pointed at it without a fork.

HTTP links without TLS for Mini Apps and Login URLs

The test environment relaxes one rule that normally slows local development: the url fields of LoginUrl and WebAppInfo also accept HTTP links without TLS. You can point a test Mini App at an address on your own machine and open it from a real Telegram client without issuing a certificate first. Production links are still expected to use HTTPS, so keep the HTTP address in a test configuration only.

Flood limits aren’t raised, and may be stricter

Telegram states plainly that flood limits are not raised in the test environment, and may at times be stricter. It also tells you not to hardcode limit values and to build retry handling into the bot instead. So use the test environment to prove that your backoff works, not to find out how fast you can send.

The simpler option: a second bot on production

Run another instance of your code on a new bot token

Before you set any of this up, consider Telegram’s first recommendation, which is lighter: create a second bot with BotFather on production and run another copy of your code against that token. Your live bot and the people using it are unaffected, and you keep the normal HTTPS setup and the normal API path.

That is often enough for day-to-day work. The test environment earns its place when you need a disposable user account or the relaxed URL rules.

file_id belongs to one bot, so re-upload media

One real limitation applies to the second-bot approach: a file_id is tied to a single bot id. Identifiers your production bot collected cannot be reused by the test bot, so any media your tests send has to be uploaded again by the bot sending it. Cache identifiers per bot rather than in one shared list.

Telegram test environment limits

Test accounts aren’t private: anyone can use the simplified login

The simplified authorization that makes test numbers convenient also makes them open, which is why the same documented sentence that explains the mechanism tells you not to put anything important or private in those messages. There is no access control to configure and no privacy setting that changes it.

Telegram wipes test data periodically

Telegram periodically deletes everything stored on test accounts. No notice is promised and no schedule is published. Anything you want to keep, including fixture definitions and test scripts, belongs in your repository rather than in a test chat.

Nothing carries over to production

A username you reserved on the test side is not reserved on production. A chat history you built up does not migrate. A bot you configured has to be configured again. Plan a final pass on production, and keep your bot’s setup in code so recreating it is one command.

Telegram test server not working: check which environment you’re in

Telegram does not publish a troubleshooting list, so work through the documented rules instead of guessing.

• Which account is the app in? A test account has none of your production chats, which is the plainest way to tell.
• Did the bot and its token come from BotFather inside the test environment? The two sides share nothing.
• Does the request path carry the /test/ segment?
• On a reserved number, is the data center digit 1, 2 or 3, is the code that digit five times over, and has the number got attempts left for the day?

For a client rather than a bot, pointing a library at the test environment means feeding it a Test DC address from the API development tools panel, not a separate API.

When a real Telegram account is still needed

Final checks on production with your own account

Some things only exist on production. Public usernames, real channel subscribers, the behavior of your bot in a group full of actual people, and anything that depends on accumulated history all need the main environment. Run them with your own account, late in the process, on a small scale.

Administrative work falls in the same bucket. A channel ownership handover, for example, moves a real channel with real subscribers and a real admin history, none of which exists outside production. Rehearse the steps on a throwaway test channel if you like, but the handover happens on the live one.

Real accounts follow Telegram’s Terms of Service

An account you use on production is governed by Telegram’s terms, and those terms cover spam and scams. Telegram’s terms do not address buying or selling accounts, so nobody can honestly tell you Telegram bans it, and nobody can tell you an account is safe either. Telegram keeps the ability to restrict or shut down an account on its own judgment, and the fallout lands on whoever is logged in.

Where bought accounts fit, and what to do first

For teams whose production checks need more than one user account, some order them rather than collecting numbers. PVAVRT lists Telegram accounts in fresh, aged and username grades, and you pick the handover format: a tdata folder for Telegram Desktop, or a session string for client libraries. Either way it arrives through the Telegram chat. If you go that route, secure the delivered session first: set your own two-step verification password, then end every other login under Settings and Devices.

For most testing, though, the free routes above cover the job: a second bot on production for bot work, and the test environment for the rest.

Ask before you order

If your production checks genuinely need Telegram accounts, ask about grades and delivery formats on Telegram @pvavrt before paying, and confirm quantity and timing in the chat. If the test environment covers what you are building, use it instead.