Broadcasts send fixed content through one Telegram account with Broadcast permission to explicitly selected private chats, groups, or channels. Immediate and one-time scheduled sending are supported. Recurring schedules, account rotation, and read-rate statistics are not included.
Broadcasts are implemented, but real Telegram recipients, multiple processes, and some failure scenarios still have acceptance checks outstanding. The deployment owner must complete the relevant checks before production use. An accessible page alone does not prove the sending pipeline works.
Create and submit a task
- Open Broadcasts, create a task, and give it a recognizable name.
- Choose a ready sending account with Broadcast permission.
- Explicitly select recipients from current or archived conversations. Use type and search filters to help; filtering does not select every matching recipient.
- Write the body, attach files, or insert an existing message template.
- Save the draft and run preflight checks. Resolve unwritable recipients, permissions, exclusions, capacity, and content-limit issues.
- Select a recipient to preview variables. To check actual delivery, use a separate test send and confirm the recipient.
- Choose immediate sending or a one-time schedule in the time zone shown on the page. Review cutoff and other policies before confirming submission.
- Review recipient results and send attempts in task details. Successful submission does not mean successful delivery.
Telegram device-style preview only displays content. Separate live test send actually sends Telegram messages to the selected recipient. A live test does not advance the main task's success progress.
Content and recipient rules
Each task uses one sending account. Telegram group, channel, and individual permissions still determine whether a recipient is writable. Platform Broadcast permission does not guarantee delivery to every recipient.
Inserting a template into a broadcast copies its text and attachments into independent content. Copied attachments consume additional workspace capacity. After submission, content and recipients are fixed; later edits to the source template do not change the submitted task.
The body supports existing variables such as {{客户}}, {{我}}, {{账号}}, and {{日期}}. Keep these literal variable names unchanged; the server generates content for each recipient. Recipient, attachment, and body limits are the limits the page obtains from the backend.
Scheduling and background processing
Check the workspace time zone when confirming a schedule. Submitted tasks run in the background; closing the browser does not cancel them. The main service, queue, and Worker must all run normally. Starting only HTTP does not provide a complete broadcast pipeline.
A scheduled time is when sending starts being arranged, not a guarantee that every recipient receives the message simultaneously. Account cooldowns, concurrency budgets, recipient errors, and cutoff policies affect progress.
Task controls and results
| Action | Effect and limits |
|---|---|
| Pause | Stops subsequent undispatched operations; calls already sent to Telegram may still complete |
| Resume | Continues processing when the task state permits, subject to current permissions and sending checks |
| Cancel | Cancels unexecuted work; does not recall messages already sent |
| Reconcile | Checks the original task's uncertain outcomes without sending new messages |
| Retry failures | Retries only message units known to have failed; successful and unknown outcomes are not resent |
| Copy to new draft | Creates an independent draft; review content and recipients before resubmitting |
| Create continuation draft | Builds a draft from eligible remaining work, excluding successful and unknown units |
Filter recipient results and historical attempts by status or reason. One recipient may have multiple messages. For partial success, inspect message units and attempt records rather than resending everything to the recipient.
An unknown outcome means the system cannot prove success or failure. Reconcile the original task and check Telegram. Do not treat an unknown outcome as a failed send to retry.
Common questions
| Symptom | What to do |
|---|---|
| No sending account is available | Check the workspace, Broadcast grants, and account runtime status |
| Preflight checks expired or the version changed | Refresh the task and run preflight checks again before submission |
| The task does not progress | Operations should check the queue, Worker, schedule conditions, and consistency between HTTP and queue configuration |
| Some recipients fail | Read the reason and distinguish Telegram permissions, exclusions, rate limits, and content errors |
| The success count increases after pausing | Previously dispatched calls may return after the pause; this does not mean new calls were dispatched |
| An old task cannot be retried or its attachments downloaded | Check retention and cleanup notices; historical content is not kept forever |
| New tasks are temporarily rejected | New-task submission may be disabled for maintenance; contact operations. Existing tasks are not automatically canceled |
Implementation references: broadcast editor, task details, and API contract.