What it means
MTProto ("Mobile Telegram Protocol") is the communication protocol Telegram designed in-house for its clients. It sits below the Telegram API surface, the schema that defines methods like messages.sendMessage, channels.getParticipants, and auth.sendCode, and handles framing, encryption, session management, and transport.
The protocol is documented at core.telegram.org/mtproto, but the underlying schema (TL, "Type Language") is the larger source of truth: over 1,000 methods and types defining the entire Telegram surface. Every official client (iOS, Android, desktop, web) and every serious third-party CRM ultimately talks MTProto.
Three pieces of context that make MTProto unusual:
- It is a binary protocol, not REST. Messages are length-prefixed TL-encoded blobs over TCP (or, on restricted networks, tunneled through HTTPS or MTProto-over-WebSocket).
- It multiplexes many calls per connection. A single MTProto socket can carry hundreds of in-flight requests, with responses arriving out of order. Reconnections do not lose pending state.
- It uses its own encryption stack. AES-256 in IGE mode, custom key-derivation, with the auth key negotiated once and reused across sessions. Not a standard TLS replacement; the encryption is opinionated and Telegram-specific.
MTProto 2.0
MTProto 1.0 shipped with the original Telegram client in 2013. After cryptographic review surfaced concerns, most notably an academic critique of the original IND-CCA properties, Telegram shipped MTProto 2.0 in 2017. The 2.0 changes were not cosmetic:
- Switched to a stronger AEAD-style encryption construction with SHA-256-based message authentication.
- Hardened the key-derivation function so the same auth key cannot be reused in subtly different message contexts.
- Tightened the message-id and salt logic to make replay and re-ordering attacks impractical.
All current Telegram clients negotiate MTProto 2.0. 1.0 is essentially deprecated and only relevant if you are working with very old historical pcaps.
MTProto vs the Telegram Bot API
This is the most common point of confusion. They are different APIs, with different capabilities, talking to the same Telegram backend.
- Bot API: a higher-level HTTPS wrapper around Telegram. JSON-in, JSON-out. Designed for bots created via @BotFather. Simple to use, fully documented at core.telegram.org/bots/api, and the right choice for most chatbot integrations. Limitations: cannot impersonate a user account, cannot proactively message users who have not started a chat with the bot, cannot scrape group history.
- MTProto: the full protocol. Can drive both user accounts and bots. Required for: sending DMs from your own phone number, scraping public groups, mass-joining channels, reading the full TL schema. Significantly more powerful, significantly more responsibility (rate limits, bans, MTProto-aware error handling).
A useful rule: "If you need it to look like a real user, use MTProto. If you need it to look like a bot, use the Bot API." CRMs that want to send from a user's own account, scrape groups, or do high-volume outbound across user accounts all need MTProto.
Why CRMs use MTProto for user-account features
The single biggest reason: only MTProto can act as a real Telegram user. The Bot API cannot. A CRM that wants the workflow "send DMs from my own account, to people who never messaged me first" cannot use the Bot API at all. That is by design, to prevent bots from spamming. Only MTProto, signed in with a real phone number and a session blob, can do that work.
Other reasons:
- Group scraping.
channels.getParticipantslets a user account read up to the visible member list of a public group. The Bot API has no equivalent. - Multi-account orchestration. CRMs run pools of user accounts for rate-limit safety. Each account has its own MTProto session; there is no "user account" concept in the Bot API.
- Full message history. User accounts can read their own chat history; bots see only messages directed to them.
- File limits. User accounts can upload up to 2 GB per file; the Bot API caps uploads at 50 MB.
Why it matters
Anyone building Telegram tooling beyond a simple chatbot ends up at MTProto. The protocol's quirks (multiplexing, session-blob persistence, MTProto-specific error responses like FLOOD_WAIT) shape how the CRM is built. A CRM that pretends MTProto is just HTTPS will hit operational walls within weeks: dropped sessions, lost messages, cascading rate limits, banned accounts.
Operationally, MTProto literacy is the difference between a Telegram CRM that scales and one that constantly reissues phone-verification SMS codes.
Real-world examples
- CRM Solid Telegram bridge. Each user account is a long-lived MTProto session backed by a persisted session blob. The blob lives in PostgreSQL with an envelope-encrypted column. Sessions reconnect automatically; flood waits are caught and respected.
- Group scraping for cold outreach. A targeted scraper paginates through
channels.getParticipantswith chunk size 100, respecting per-method rate limits. The same job via Bot API would be impossible; bots have no scraping surface. - Multi-account warming. A pool of 20 user accounts each authenticated via MTProto, joining a handful of channels per day, posting in groups, and receiving cosmetic activity to look human before any outbound campaign begins.
- Cross-device sign-in. A new client logging into an MTProto session triggers a confirmation dialog on every other signed-in device, a feature only possible because the same auth key drives every device.
- TDLib in a desktop app. Telegram's own TDLib library wraps MTProto for embedded clients. Our PC_APP uses TDLib to talk to the same backend the iOS app does.
Common mistakes
- Treating the session blob as disposable. The session blob IS the account on that machine. Losing it forces re-verification by SMS, and after a few re-verifies Telegram restricts the number.
- Not handling FLOOD_WAIT. MTProto rate limiting is not optional. See the dedicated flood wait entry.
- Mixing Bot API and MTProto sloppily. A bot can be controlled by either, but you cannot use Bot API calls on a user account, and vice versa. Picking the wrong surface for a feature wastes weeks of engineering.
- Ignoring MTProto error types.
AUTH_KEY_UNREGISTERED,SESSION_REVOKED, andUSER_DEACTIVATED_BANeach require different recovery flows. Catching them all as "generic error" leads to silent account failures. - Building a Telegram CRM on the Bot API only. Works for bot-channel use cases. Fails the moment you need user-account behavior, and you will.
Related concepts
- Flood wait: the MTProto rate-limit response, and the most common runtime error you will see.
- Spintax: content variation that reduces the duplicate-content signal MTProto-level spam detection looks for.
- Cold outreach: the workflow MTProto enables that the Bot API does not.
- Omnichannel CRM Telegram-via-MTProto is one of the channels a real omnichannel CRM must support.
- Webhook: MTProto client events (new message, account banned, flood wait triggered) typically translate to webhook fire-and-forget for downstream systems.
- AI agent: agents on Telegram run on MTProto sessions when they need to act as a real user.
How CRM Solid handles it
CRM Solid uses WTelegramClient, a production-grade MTProto library, to back every Telegram user-account feature. Sessions are persisted in PostgreSQL with envelope encryption, reconnect automatically, and survive machine restarts. Flood waits and account errors are caught and routed into the right recovery flow (back-off, cooldown, operator alert). The Bot API is used in parallel for bot-only features. Both surfaces feed the same unified inbox.