GLOSSARY

What is a Userbot?

A userbot is automation that logs in as an ordinary Telegram user account over MTProto instead of using a bot token, which lets it do everything a human can do: message people who never wrote first, join groups by invite link, read full history, and list members. That capability comes with real account risk, because Telegram polices behaviour on user accounts far harder than it polices bots.

Try Pinlyx freeSee live demo

Free forever plan · No credit card required · Cancel anytime

Quick definition

A userbot is automation that logs in as an ordinary Telegram user account over MTProto instead of using a bot token, which lets it do everything a human can do: message people who never wrote first, join groups by invite link, read full history, and list members. That capability comes with real account risk, because Telegram polices behaviour on user accounts far harder than it polices bots.

In a single sentence: a bot is an account Telegram gave you, a userbot is a person Telegram thinks you are.

What it means

Telegram has two kinds of account. A bot is created by BotFather, authenticated with a token, and flagged as a bot everywhere. A user is created with a phone number, authenticated with a session, and has all the capabilities a human needs.

A userbot is software driving the second kind. It logs in with auth.sendCode and auth.signIn, handles the two-factor step if the account has one, and from that point talks MTProto exactly as an official Telegram client would. The API credentials come from my.telegram.org as an api_id and api_hash pair, and Telegram issues them to anyone who asks, because third-party clients are a supported part of the ecosystem.

Nothing on the wire distinguishes a userbot from a person using a third-party Telegram client. That is precisely why the capability exists, and precisely why abusing it is policed so aggressively.

What only a user account can do

The full comparison is in the table below, but four capabilities account for essentially every reason a team ends up running a userbot:

  • First contact. A bot cannot message a person who has not started it. A user account can message anyone it has a valid access hash for.
  • History. A bot sees nothing sent before it joined. A user account reads whatever the chat allows.
  • Membership. There is no Bot API method to enumerate a group's members. Over MTProto, channels.getParticipants exists, subject to a server-side result cap and, in large groups, an admin restriction.
  • Joining. A bot must be added by a human. A user account can act on an invite link hash itself.

The trade runs both ways, which is the part that gets left out of most descriptions. Inline keyboard buttons, callback queries, inline mode, and payment flows are bot-only. A user account cannot attach reply markup to a message under any circumstances. Anyone who replaces their bot with a userbot to "get more capability" loses every interactive feature they had.

The risk, described honestly

Running a userbot means putting a real account, tied to a real phone number, in front of Telegram's anti-spam systems. Those systems are automatic, opaque, and mostly not appealable.

The escalation path is consistent enough to plan around. It starts with short flood waits on messages.sendMessage. Ignored, the waits lengthen. Next comes PEER_FLOOD, which is qualitatively different: no countdown, no number, just an account that can no longer message non-contacts. After that comes a full spam block, and finally USER_DEACTIVATED_BAN, at which point the account and its phone number are gone.

The trigger that matters most is not volume. It is the spam-report rate. An account sending 40 well-targeted messages a day to people who find them relevant will run for months. The same account sending 40 irrelevant messages a day will collect reports, and reports move you down the escalation path far faster than throughput does. This is why "how many can I send" is the wrong question and "who am I sending to" is the right one.

A practical tool worth knowing: messaging @SpamBot from a restricted account tells you the current restriction status and offers an appeal path. It is the only visibility Telegram gives you into your own standing.

Operating a pool safely

The numbers below are Pinlyx production defaults, and they are deliberately conservative.

  • Warm up for at least 7 days. A new account that sends a cold DM on day one almost always earns an immediate flood wait. Receive messages, join a few relevant channels, set a photo and a bio, have a real conversation.
  • 20 messages an hour, 50 a day per account to contacts who have never written to you.
  • At least 10 seconds between any two sends from the same account, with jitter, because perfectly regular intervals are themselves a signal.
  • Rotate across at least three accounts for any campaign above a hundred sends, and slow down the whole pool when one account gets a wait, not just that account.
  • Vary the message. Identical strings across hundreds of sends are trivially detectable. See spintax.
  • Stop on reply. Once a person answers, the sequence has done its job. Continuing to send scheduled steps into a live conversation is the single most reportable behaviour in outbound.

Why it matters

For a CRM, the userbot question is the difference between two business models. A product built only on the Bot API can serve inbound conversations beautifully and can never do outreach. A product that also drives user accounts can do lead generation on Telegram, which is where most of the commercial demand is, especially in markets where Telegram has replaced email for business conversation entirely.

The engineering that separates a viable implementation from a dangerous one is not glamorous: per-account rate limiting, honest flood-wait back-off, a per-account peer cache, stop-on-reply, opt-out handling, and an operator alert when an account's error profile changes. Skip those and you have built an account shredder with a nice interface.

Common mistakes

  • Sending on day one. Warm-up is not optional and cannot be shortened by sending more slowly.
  • Hot-switching accounts on every flood wait. The pool then produces the same wait on the next account ten minutes later. Slow down globally.
  • Treating PEER_FLOOD as a longer flood wait. It is a different class of event and needs a full stop.
  • Buying the cheapest virtual numbers. They are pre-flagged. The saving disappears the first time a batch gets banned.
  • Sending the same string to everyone. Duplicate content is one of the easiest signals for a platform to detect.
  • Replacing a working bot with a userbot. You lose buttons, callbacks, inline mode and payments, and gain risk you did not need.

Related concepts

  • MTProto: the protocol a userbot speaks.
  • Session string: the credential that keeps it logged in, and the thing to protect.
  • Flood wait: the first warning on the escalation path.
  • Telegram Bot API: the safer half of the architecture.
  • Business connection: the sanctioned way to automate a personal account, with no session and no ban risk.
  • Spintax: how to keep bulk messages from looking like bulk messages.

How Pinlyx handles it

Pinlyx runs user accounts through WTelegramClient with a rate limiter configured per account: 20 messages an hour and 50 a day by default, a 10-second minimum gap, and exponential back-off on FLOOD_WAIT. Long waits pause the account for the rest of the day automatically, and PEER_FLOOD halts it entirely and notifies the operator rather than retrying. Account rotation is per-account aware, so one paused sender does not stop a campaign. Sequences stop on reply by default. Everything that a bot can do is done by a bot, because the safest userbot action is the one you never had to take, and the whole thing sits inside the Telegram CRM rather than in a standalone script.

Decision table · bot or user account

Eight capabilities that decide the architecture.

Note that the trade runs in both directions. A userbot is not a superset of a bot.

Message someone who never contacted you

BotNoUserYes

The single reason userbots exist. A bot has no way to reference a user it has not met.

Read group history from before you joined

BotNoUserYes

Bots see nothing that predates their membership. User accounts read whatever the chat allows.

List the members of a group

BotNoUserLimited

No Bot API method exists. Over MTProto it works, subject to a server-side result cap and admin restrictions on large groups.

Join a group from an invite link

BotNoUserYes

A bot must be added by a human. A user account calls messages.importChatInvite.

Attach inline keyboard buttons

BotYesUserNo

Reply markup is a bot-only feature. No user account can send a message with buttons, at any price.

Receive callback queries and run inline mode

BotYesUserNo

Interactive UI belongs entirely to bots. This is the half of the trade people forget.

Survive high message volume

BotYesUserLimited

A bot hits documented rate limits and recovers. A user account collects flood waits and can be restricted permanently.

Be revoked without losing anything

BotYesUserNo

Rotate a bot token in one BotFather command. A banned user account takes its phone number with it.

Cheat sheet · the escalation path

How a healthy account becomes a banned one.

Each stage is a chance to stop. Most teams find out about stage three by reading their error logs after the fact.

1  FLOOD_WAIT_30          routine throttling, sleep and continue
2  FLOOD_WAIT_3600        systematic problem, pause the account for the day
3  PEER_FLOOD             no number, no countdown: cannot message non-contacts
4  spam block             visible restrictions across the account
5  USER_DEACTIVATED_BAN   account and phone number are gone

// Stage 3 on the wire. Note what is missing: a duration.
{
  "_": "rpc_error",
  "error_code": 420,
  "error_message": "PEER_FLOOD",
  "method": "messages.sendMessage"
}

// The wrong handler
catch (e) { await sleep(60_000); retry(); }   // escalates to stage 4

// The right handler
catch (e) {
  if (e.message === 'PEER_FLOOD') {
    haltAccount(account, 'peer_flood');
    notifyOperator(account);                   // a human decides what changed
    return;                                    // no retry, no rotation
  }
}

// Check your own standing at any time: message @SpamBot from the account.

Reports beat volume

Relevance protects an account better than any rate limit setting.

PEER_FLOOD is not a wait

No duration is supplied because there is no automatic recovery to wait for.

A number, not a token

A banned account cannot be rotated. The phone number goes with it.

Operating checklist

Six rules for running user accounts that stay alive.

  • Warm every account for at least 7 days before the first cold message.
  • Cap at 20 messages per hour and 50 per day per account, with a 10-second minimum gap.
  • Give every send a different string. Identical bulk text is the easiest signal to detect.
  • Stop the sequence the moment someone replies, on every channel.
  • On PEER_FLOOD, halt the account and involve a human. Never rotate around it.
  • Let the bot do everything a bot can do. Reserve user accounts for first contact only.
Watch out for

"Unlimited Telegram sending" is a claim about a script, not about Telegram.

Any tool advertising unlimited or unrestricted messaging from user accounts is describing what its own code will attempt, not what the platform will allow. Telegram's limits are enforced server-side and apply identically to every client. The only variable a tool actually controls is how gracefully it handles being told to stop, and the tools that promise no limits are exactly the ones that handle it worst.

Userbots: FAQ

The questions worth answering before you put a real phone number behind an automation.

Third-party clients are explicitly allowed. Telegram publishes the protocol, hands out api_id and api_hash credentials at my.telegram.org, and maintains its own open-source client library, so automating a user account is not forbidden by itself. What gets punished is behaviour: unsolicited bulk messaging, mass adding people to groups, and anything that generates spam reports. The rules you are actually operating under are the anti-spam ones, and they are enforced automatically and without appeal in most cases.
Identity. A bot is a separate account type created by BotFather, authenticated with a revocable token, and marked as a bot everywhere in the interface. A userbot is a real user account, authenticated with a phone number and a session, indistinguishable from a person on the wire. That difference decides everything else: bots cannot start conversations or read old history, and user accounts cannot send buttons or run inline mode.
Far fewer than people expect. Our production defaults are 20 messages an hour and 50 a day per account to fresh contacts, with a minimum of 10 seconds between sends, and those numbers are conservative on purpose. The binding constraint is not the rate limit, it is the spam-report rate: a handful of recipients pressing "Report spam" will restrict an account that never hit a single flood wait. Volume comes from more accounts and better targeting, never from raising the per-account cap.
PEER_FLOOD is the restriction Telegram applies when it decides an account is behaving like a spammer. Unlike a flood wait it carries no number, because there is no countdown: the account simply cannot message non-contacts any more. It usually lifts after a cooldown measured in days, and you can check status and appeal by messaging @SpamBot from the restricted account. Treat any PEER_FLOOD as a stop-everything event, because continuing to send through it is what turns a temporary restriction into a permanent one.
Yes. A Telegram account is a phone number, and accounts cannot be created without one. That is the real cost centre of running a userbot pool, and it is also the risk concentration: a banned account burns the number with it. Numbers from bulk virtual providers get flagged much faster than ordinary mobile ones, which is why cheap numbers usually turn out to be the expensive option.
That is the correct architecture, and it is what serious Telegram products do. Use the bot for everything inbound: the support inbox, notifications, buttons, payment flows, anything where the customer starts the conversation. Use the user account only for the specific actions a bot cannot perform, which is essentially first contact and group research. It keeps the risky surface as small as possible while giving you the full feature set.

Keep reading

Telegram Bot API

The safer half of any serious Telegram architecture.

Flood wait

The first warning, and how to back off correctly.

Session string

The credential that keeps a userbot logged in.

Business connection

Automating a personal account with Telegram's blessing instead.

Avoid Telegram bans

A 30-day warm-up protocol that keeps accounts alive.

Telegram CRM

Bots and user accounts running side by side, safely.

Ready to ship

Reach anyone on Telegram. Keep every account.

Pinlyx paces every send, backs off on flood waits, halts on PEER_FLOOD, and stops the sequence the moment someone replies.

Start freeTalk to sales

Free forever plan · GDPR-ready · No credit card required

We value your privacy

We use cookies to improve our site, analyze traffic, and personalize ads. You can accept all, reject non-essential, or customize your choices. Read our Cookie Policy.