You cannot use the Telegram Bot API for cold outreach. Bots can only message users who have started a conversation with them first. Every Telegram outreach tool, without exception, works through user accounts via a client library such as Telethon or TDLib. That is a platform constraint, not a design choice, and it determines everything about how safe outreach works.
What is the difference between the Bot API and a client library?
Telegram exposes two fundamentally different interfaces.
The Bot API is the sanctioned, documented interface for automated accounts. A bot has a token, a username ending in "bot", and clearly signals its nature in the interface. It is the right tool for support flows, notifications, group moderation and commands.
MTProto is the protocol the actual Telegram clients speak. Libraries like Telethon (Python) and TDLib (C++) implement it. Through MTProto you authenticate as a real user account with a phone number, and you can do anything the official app can do.
The distinction that matters for outreach is one line in Telegram's own documentation: a bot cannot initiate a conversation with a user. The user must message the bot first, or click a deep link, or add it to a group. There is no endpoint that lets a bot send an unsolicited direct message.
So the moment your use case is "message a founder who has never heard of us," the Bot API is off the table.
Why does Telegram restrict bots this way?
Because unsolicited bot messages would make the platform unusable. The restriction is the reason Telegram DMs still get read.
It also explains the shape of the entire outreach tooling market. Every product in this category, Zupai included, connects user accounts. They differ in how carefully they behave once connected, not in whether they use MTProto.
What are the practical consequences of using a user account?
Four, and they are the whole game.
You carry ban risk. A bot that misbehaves gets its token revoked. A user account that misbehaves gets the phone number banned. That number is often tied to a real SIM, and recovering it is difficult.
Rate limits are behavioural, not documented. The Bot API publishes explicit limits. MTProto does not. Telegram's spam detection watches for patterns: volume spikes, identical message bodies, high rates of "user has blocked" or reported. There is no published threshold, only observed behaviour.
Sessions are stateful and portable. Telethon authenticates once and stores a session. That session is the account. Losing it means re-authenticating with an SMS code. Storing it as a file on one machine means only that machine can use the account, which is the single most common architectural mistake in this category.
Flood waits are a normal part of operation. Telegram will return a FloodWaitError asking you to wait N seconds. This is not a ban. Handling it gracefully, rather than retrying, is the difference between an account that survives and one that does not.
What sending rate is actually safe?
Telegram publishes no number for user accounts, so anything you read is inferred from operation.
Our default is five direct messages per account per day, with a hard ceiling of thirty that a user can raise to only deliberately. Between messages we pace at roughly eight minutes. Those numbers are conservative on purpose. A new account should sit at the low end for its first two weeks.
What matters more than the raw number:
- Message variation. Fifty identical messages is the clearest spam signal available. Personalisation is not only more effective, it is safer.
- Account age and activity. A number registered yesterday that immediately sends is behaving like nothing a human does.
- Reply and block rates. If recipients block or report you, no rate limit saves the account. Relevance is a safety feature.
- Bursts versus spread. Ten messages in ten minutes is worse than ten messages across a working day.
What does a Telethon session actually contain?
An authenticated session holds the auth key, the data centre the account is homed to, and enough state to resume without re-authenticating. Telethon offers two storage backends.
File sessions write a SQLite file to disk. This is the default, and it is where most implementations stop. It works until you run more than one process, at which point SQLite locking produces intermittent database is locked errors, and it works until you add a second server, at which point the second server cannot see the file at all.
String sessions serialise the same state into a string you can store anywhere, including a database column. This makes an account portable: any worker on any machine can load it, connect, and send. Encrypting that string at rest is not optional, because the string is the account.
If you are building on Telethon and intend to scale beyond one box, use string sessions from the beginning. Migrating twenty-four live accounts from files to strings is possible but requires stopping the service, and one of ours had expired by the time we did it.
When should you use the Bot API instead?
Whenever the user has opted in. Bots are the correct, safe, sanctioned tool for:
- Notifications and alerts to people who requested them
- Support and command interfaces inside your own community
- Group moderation
- Anything where the user starts the conversation
A well-designed outreach system often uses both: MTProto user accounts for the cold first touch, and a bot for internal alerts to your own team when a reply arrives.
Frequently asked questions
Can a Telegram bot send a message to a user first?
No. Telegram's Bot API does not permit a bot to initiate a conversation. The user must message the bot, click a deep link, or add it to a group first. This is why every cold outreach tool uses user accounts through MTProto rather than the Bot API.
Is Telethon against Telegram's terms of service?
Telethon implements MTProto, the same protocol the official clients use, and Telegram publishes the protocol specification. Using it is not itself a violation. What triggers restrictions is behaviour: high volume, identical messages to strangers, and recipient reports. The library is not the risk, the pacing is.
How many DMs can you send from a Telegram account per day?
Telegram publishes no limit for user accounts. Operationally, five per day per account is a safe default and thirty is an aggressive ceiling that only aged, active accounts should approach. Bursts matter more than totals, and identical message bodies matter more than either.
What is a Telethon StringSession?
A serialised form of an authenticated Telegram session that can be stored in a database rather than as a file on disk. It makes an account portable across machines, which is required for horizontal scaling. Because the string is equivalent to the account, it should be encrypted at rest.
What causes a FloodWaitError?
Telegram returns a FloodWaitError when it wants you to slow down, specifying a number of seconds to wait. It is a rate limit, not a ban. Waiting the specified duration is correct. Retrying immediately, or rotating to another account to send the same message, is how a rate limit becomes a ban.
Zupai stores every Telegram session encrypted in the database, defaults to five DMs per account per day, and generates a distinct pitch for every lead. Start a free 5-day trial or read the product guide.