Test data centres

What test DCs are

Production has five DCs. Next to them, on different IP ranges, is a testcluster with the same DC numbers but completely separate data. Same MTProto, same TL schema, same RPC methods. Different rate limits (looser), different auth keys, different bots, different state.

Spinning up a test session never touches prod. You can freely create accounts, send nonsense messages, and break things without consequence.

Test phone numbers are gone

Today you sign in to the test environment with your real phone number. The server delivers an actual verification code — usually as a Telegram service message on prod, since the test backend has no SMS gateway of its own. Yes, that means you have to be signed in on prod (on the same phone) to read the test-env code.

Pragmatic flow: sign in with your prod number once into the test environment, save the resulting session file, reuse it for every subsequent run. The auth key persists; you do not have to repeat the dance.

Credentials and bots

• API id / hash: reuse your production credentials. Telegram does not issue separate dev keys.
• Bot tokens: production tokens do not work in test mode. To get a test-env bot, message the test-env BotFather. Open web.telegram.org/k/?test=1 while signed in on prod, sign in with your phone again (separate session), then talk to @BotFather there. The token it gives you is test-env only.

Connecting

Flip one boolean, optionally pick a starting DC:

client, _ := telegram.NewClient(telegram.ClientConfig{
	AppID:      12345,
	AppHash:    "...",
	Session:    "test.session",
	TestMode:   true,
	DataCenter: 2,
})

client.Connect()
client.Login("+15551234567") // your real phone, not a fake one

client, _ := telegram.NewClient(telegram.ClientConfig{
	AppID:      12345,
	AppHash:    "...",
	Session:    "test.session",
	TestMode:   true,
	DataCenter: 2,
})

client.Connect()
client.Login("+15551234567") // your real phone, not a fake one

With TestMode: true, the client uses the test DC IP list and the test environment's RSA public keys. DataCenter picks the starting DC for the handshake; if your account lives elsewhere, migration is automatic just like in prod.

Test DC addresses

Telegram's test environment lives mostly in DC 1 and DC 2; DCs 3, 4, and 5 are defined but largely empty. WebSocket access lives at wss://[dc-name].web.telegram.org/apiws/test.

Other differences from prod

• Rate limits are relaxed but not absent — you can still trip FLOOD_WAIT on the test backend with tight loops.
• Account lifetime is short. Test accounts can be reset by Telegram without notice. Do not rely on long-lived test state.
• Some methods are stubbed. Payments, premium upgrades, real calls — these route to test endpoints or no-op.
• No SMS, no calls. Verification codes only arrive as in-app Telegram service messages.
• Two-factor lives separately. Setting a 2FA password in test does not affect prod and vice versa.

Session isolation