A large Telegram broadcast should be a resumable queue, not one long PHP loop. Process a bounded batch, store progress, and pause for the exact retry_after value whenever the Bot API returns HTTP 429.
Last updated: November 8, 2026.
<?php
foreach ($recipients as $chatId) {
$result = sendTelegramMessage($chatId, $text);
if (($result['error_code'] ?? null) === 429) {
$delay = (int) ($result['parameters']['retry_after'] ?? 1);
sleep(max(1, $delay));
retryLater($chatId);
continue;
}
markDelivered($chatId, $result['result']['message_id'] ?? null);
}The send function must retain the response body for non-2xx requests and use finite connection and read timeouts. Do not log the bot token. Persist each recipient’s status so a process restart does not resend the entire campaign.
Apply every relevant limit
The official Telegram Bots FAQ advises avoiding more than one message per second in one chat, more than 20 per minute in a group, and about 30 broadcast messages per second under the free limit. A global average below 30 does not protect a hot individual chat or group.
The Bot API documentation defines ResponseParameters.retry_after for flood-control errors. Treat it as the authoritative delay for that response and add small randomized backoff before retrying.
Make the job resumable and memory-bounded
Read recipients in primary-key order with a fixed batch size instead of loading hundreds of thousands of rows into PHP memory. Claim a batch, send it, store success or failure, release memory, and let the next worker continue. Use an idempotency key such as campaign ID plus chat ID to prevent duplicate sends.
Separate permanent errors—blocked bot, invalid chat, or forbidden—from transient network and 429 responses. Cap retry attempts, record the last error code, and monitor delivery rate. On shared hosting, run short cron invocations; on a VPS, use a supervised queue worker with memory and lifetime limits.
Continue with queue workers on shared hosting, cURL multi error handling, and idempotent API operations.
