Growing

How to broadcast a message to all your Telegram bot users

By the Botable team

Broadcasting means sending to every stored user id, paced under Telegram's rate limits, with progress saved so a crash resumes rather than restarts. Blocked users return an error you should use to prune your list.

The short version

Broadcasting from a Telegram bot is a queue problem wearing a marketing hat. You hold a list of user ids and must send to each without exceeding Telegram's rate limits, which means a paced worker rather than a loop — a broadcast to a few thousand users is minutes of work, not an instant operation. Three things separate a broadcast that works from one that causes a support incident. Progress must be persisted per recipient, so a crash halfway resumes rather than starting again and double-messaging everyone who already received it. Failures must be classified: a user who blocked the bot returns a specific error, and that user should be marked inactive rather than retried forever. And consent has to come first, because a bot that broadcasts to people who only ever used one command will be blocked and reported, which damages deliverability in a way no pacing strategy recovers.

Step by step

Who should receive a broadcast?

People who opted into one. Interacting with a bot once is not consent to be messaged later, and treating it as such produces blocks and reports. An explicit subscribe, or a clear notice at first use, costs a little reach and protects the channel.

How do you pace the sends?

A worker that respects Telegram's per-chat and aggregate limits, with a small delay between sends. On a 429, wait exactly the retry-after and continue. Plan for a large broadcast to take minutes and design the interface so nobody expects otherwise.

How do you make it resumable?

Record the outcome per recipient as you go — sent, failed, blocked — rather than tracking a single position. A crash then resumes precisely, and the record doubles as the delivery report you will want afterwards.

What do you do with failures?

Distinguish them. A block is permanent: mark the user inactive and stop sending. A rate limit is temporary: retry after the delay. A transient network error is worth one retry. Treating all three the same means either retrying blocked users forever or dropping people over a blip.

What catches people out

  • A single position marker instead of per-recipient status means a crash re-sends to everyone already done
  • Blocked users are permanent failures — retrying them forever wastes your entire rate budget
  • Broadcasting without consent produces blocks and reports, and neither is recoverable

Questions

How long does a broadcast to 10,000 users take?

Minutes, under Telegram's limits. That is normal and not a fault to engineer around. Show progress in your admin interface so nobody assumes it has hung and starts it again.

Can I segment a broadcast?

Yes, and you should — by activity, by language, by whatever you store. A smaller, relevant send produces fewer blocks than a large generic one, and blocks are the expensive outcome.

Want a bot that does this?

Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you — the token, the webhook, the storage, the hosting.

Build a bot

Keep reading

Bots that use this

All twenty-five guides