Automated report delivery to partners in Telegram

The problem

A company with a large partner network regularly sends partners report files over Telegram — hundreds of deliveries a week, different report types, all managed from Bitrix24 and kept with history. The old setup relied on a single handler that, whenever Bitrix was unreachable, silently failed to start the delivery — and reports were simply lost, with no trace and no retry.

Before

• All delivery ran through one handler: on a network failure to Bitrix it silently failed to find the company and never started the send.
• In one incident, a network block lost the bulk of a week's reports this way — with no notification that anything had gone wrong.
• The Telegram-chat binding for a partner stored their identifier right in the invite link — a potential leak.

What we did

• We rebuilt delivery into a resilient pipeline: an item in Bitrix24 hits a thin receiver that instantly drops the task into a file queue, and a background worker under systemd processes it one by one.
• The key change: if Bitrix is temporarily unreachable, the task is not removed from the queue — the worker waits and retries. A network failure turned from a lost report into a short delay, and the business process never fires twice.
• Down the chain: the business process puts the file on the Drive, a Go service generates a public link, and the bot sends the report to the partner in Telegram.
• Separately we closed the security of chat binding: instead of the partner's identifier in the link, one-time salt codes are used, one active link per partner.

Results

• The pipeline handles a peak of around 5,895 deliveries a week across dozens of report types.
• Bitrix network failures no longer lose reports — the queue drains once the connection is back.
• Telegram binding no longer exposes partner identifiers.
• The full send history lives in Bitrix24 and is managed by a manager without a developer.