Broadcasts to hundreds of thousands
without infrastructure pain

One JSON line — millions of messages. Queue, retry, personal variables, segments and real-time progress. While you sleep, the broadcast runs.

· Throttling 5 s, retry 3×, HMAC webhooks

job_id: b7f3...
Version 2.0 announcement
pending
0 / 2859 0.0%
sent
0
failed
0
POST /v1/broadcast retry 3× · webhook broadcast.completed
100,000
subscribers per broadcast
Redis
queue with dedup
retry with exponential backoff
Live
sent / failed in real time

Without us

Building broadcast yourself is infrastructure

Queue, workers, monitoring

To stay alive at 10,000 sends you need Redis/RabbitMQ, a worker, failure monitoring, and dedup.

Platform rate limits

Telegram and Max ban bots for bursts. You need throttling ~30 msg/s, gradual ramp-up, scheduling.

Personalization and segments

"Hi, John…" — that's per-recipient variable rendering. Without a template engine and JOIN to subscriptions — won't fly.

What's inside

Everything needed for mass sends

Personal variables

{{first_name}}, {{username}}, {{subscriber_id}}, {{lang}} — rendered per recipient via render_subscriber_vars.

Segments and permissions

Filters by channel/segment/permission. Broadcast only to vip-tagged or orders-permissioned users. count_subscribers_filtered returns real totals.

Progress sent / failed

Poll GET /v1/broadcast/:job_id — pending → processing → completed with real counters. The broadcasts table stores history.

Media + buttons

Photos, videos, inline buttons with URL or callback_data. Same shape as /v1/send — consistent with personal notifications.

broadcast.completed webhook

On completion you get an event with total/sent/failed. No polling — push model with HMAC-SHA256 signature.

Dedup and recovery

On worker restart — recover_stale_jobs via rpop. No job ships twice. Status check before entering processing.

How it works

From launch to webhook.completed

01

POST /v1/broadcast

Send text or template, optional filters (channel, segment, permission). Response: job_id and pending status.

02

Queue and worker

Job goes into a Redis List. A worker with BRPOP picks it up, loads filtered subscribers, sends one-by-one with 5 s delay.

03

Progress and completion

Get progress via GET /v1/broadcast/:job_id or wait for the broadcast.completed webhook with final metrics.

FAQ

Frequently asked

With current throttling (5 s between messages) — about 14 hours. Throughput ~17 msg/min. For critical cases, enterprise plans give extended limits.

Those records are auto-deactivated and skipped. The failed counter reflects other errors — bot muted, media too large, caption length, etc.

Yes. DELETE /v1/broadcast/:job_id stops the worker at the next iteration. Already-sent messages — cannot be recalled.

Up to 100,000 per broadcast. For larger lists, split by segments (e.g., permission or subscription date).

Yes. The broadcasts table keeps every run with metrics. Visible in the dashboard with filters and search, accessible via API.

1 credit per successful delivery to a subscriber. Failed deliveries are not charged. 10,000 successful sends = 10,000 credits.

Free to start

Hook up in 5 minutes

No credit card. 100 free credits per month — enough to try every feature.