Telegram is changing MTProto.
What to prepare for June 2026.

Telegram publishes MTProto changes through API Layers. Each layer is an increment: methods are added, some are marked deprecated, schema types change. The current layer (at the time of publication) is ~180.

Most updates are soft. Telegram rarely breaks backward compatibility in a single day. The typical flow: a new method appears → the old one is marked deprecated → the deprecated one keeps working for another 6-12 months → then it's removed.

But in 2026, a major consolidation is expected — several transitions at once, which collectively will make old custom clients unusable. Here's what specifically.

Session-string v2: what's changing

A session-string is a serialized auth key your client uses to log into Telegram without re-authenticating. Historically, different clients used different formats: telethon — pickle+base64, pyrogram — custom binary.

Telegram is moving to a standardized format with backward compatibility. The new format contains:

• Version tag (1 byte) — for future migrations
• DC id + auth_key (256 bytes) — as before
• Device fingerprint metadata — app_version, device_model, system_version are stored in the session-string (not set per-call)
• Creation timestamp — for aging detection

What breaks: clients that used to generate session-strings and pass the fingerprint on every connection now need to embed the fingerprint into the session itself. Otherwise — Telegram returns AUTH_KEY_UNREGISTERED.

New flood headers: more granular rate-limiting

The classic FLOOD_WAIT_X is Telegram's single way to say "hold on". The new scheme introduces differentiated headers:

The split gives Telegram the ability to throttle in a targeted way without blocking the whole account. For clients it means: you need to distinguish FloodWait types and handle them accordingly.

Endpoints on the way out

Based on observed deprecation patterns, the following methods are in the risk zone:

• auth.importAuthorization — used to transfer a session between DCs. Being replaced by server-side automatic DC affinity.
• channels.GetParticipants with the ChannelParticipantsRecent filter — returned the last N participants. Being replaced by channels.GetStatistics for aggregations.
• messages.SearchGlobal — global search across all chats. Being tightened — will be available only to Premium accounts.

What to do for clients on telethon / pyrogram

If you have your own fork of a popular Python library:

1. Update to latest — the library author usually patches new layers within 1-3 weeks. Follow GitHub releases.
2. Migrate session storage — if you cache session-strings in your DB, you'll need to regenerate all sessions under the v2 format.
3. Distinguish FloodWait subtypes — instead of a single except FloodWait, use 3-4 different ones with matching handling.
4. Log warnings — Telegram often ships non-fatal warnings for deprecated methods. If you don't log them, you'll miss the upcoming deprecation.

If TDLib

Updating TDLib automatically pulls all schema changes. Usually just git pull && rebuild. Session format changes are most often transparent (the library re-encodes in the background).

If SaaS

Ask your vendor: "when is the migration to the new MTProto layer planned?". A normal answer is "already done, clients didn't notice". If the answer is "someday in the future" — red flag.

Why migrations don't worry us

Our MTProto client is written at the level of a custom TDLib fork + our own schema layer. API changes are handled centrally:

• We monitor Telegram's GitHub and core.telegram.org daily
• We beta-test new layers on test accounts 1-2 weeks before prod rollout
• Pushing updates to clients is transparent, via desktop auto-update
• Session storage is on our side — reconversion on first connect

For the user this means: you don't think about MTProto. Telegram changes a layer → you don't notice.