Automation
Tasks, campaigns, flows, and anti-ban guardrails
Automation is the core of the platform. You can schedule messages, build multi-step campaigns, and set up auto-reply rules. All with anti-ban pacing that protects your accounts.
Three primitives
| Primitive | Scope | Persistence |
|---|---|---|
| Task | One-shot action to a single target | Executes once, then archived |
| Campaign | Multi-step sequence across targets | Persists until all steps complete or you cancel |
| Flow | Recurring or event-triggered rule | Runs indefinitely until paused or deleted |
Task types
| Type | Description |
|---|---|
| send_dm | Send a direct message to a user |
| send_group | Send a message to a group or channel |
| join_group | Join a Telegram group by invite link |
| leave_group | Leave a Telegram group |
| react | React to a message with an emoji |
| forward | Forward a message from one chat to another |
| schedule_broadcast | Schedule a broadcast to multiple recipients |
Warm-up schedule
Every new account spends its first 14 days in warm-up. The hourly send budget grows in four stages:
| Stage | Days | Hourly budget | Activities allowed | 10-sec burst max |
|---|---|---|---|---|
| read_only | 1-3 | 0 | Inbox observation, no outbound | - |
| light | 4-6 | 5 | DMs only, no group messages | 1 |
| moderate | 7-10 | 15 | DMs + groups, no bulk sends | 3 |
| pre_active | 11-14 | 25 | All message types except broadcasts | 5 |
| active | 15+ | 30 | All types including broadcasts | 8 |
Cannot skip warm-up. Warm-up is enforced at the runtime level and cannot be bypassed. Attempting to exceed the per-stage budget results in a flood-wait error and resets the stage timer.
Anti-ban guardrails
Jitter
All automation has a configurable jitter window (default: ±30% of the send interval). The runtime randomizes the actual send time within this window so messages do not appear to follow a rigid machine schedule.
Example: a task set to send every 10 minutes with 30% jitter has actual send times at 7-13 minute intervals.
Global 10/sec ceiling
No single account can send more than 10 messages per second in aggregate. This ceiling applies across all task types (DMs, groups, broadcasts). The ceiling is enforced at the runtime process level. Exceeding it queues messages until the next second window.
Flood-wait detection
When Telegram returns a FLOOD_WAIT error, the runtime:
- Records the wait duration from the error response.
- Sets the account status to
cooldownfor the wait duration plus a 10% safety margin. - Queues any pending outbound messages for delivery after the cooldown expires.
- Reports the flood-wait event in the account event log.
Repeated flood-wait events (3+ within 24 hours) trigger a health score penalty of -15 per event.
Health-score gating
Automation execution is gated on account health scores:
- 80-100: All tasks, campaigns, and flows execute normally.
- 50-79: New bulk-send tasks are refused. DMs, replies, and group messages are unaffected.
- 25-49: Bulk send and group join tasks are refused. DMs and replies unaffected.
- 1-24: Outbound is paused. Existing connections stay open but no new sends are attempted.
- 0: Account is suspended. Automations are not scheduled for it.
Auto-reply rules
Auto-reply rules let you define automatic responses to incoming DMs. Rules are evaluated in order, and only the first matching rule fires.
| Match type | Description | Example | |
|---|---|---|---|
| exact | Message text exactly equals the trigger | "Help" triggers reply | |
| contains | Message text contains the trigger substring | "price" in "What is the price?" triggers reply | |
| regex | Message text matches a JavaScript regex pattern | `/^hi | hello/i` triggers reply |
| any | Any incoming DM triggers the reply | Catch-all for out-of-office |
Each auto-reply rule has:
- Trigger: the match pattern (not used for
anytype) - Match type: one of
exact,contains,regex,any - Reply text: the message to send back (max 1000 characters)
- Cooldown: minimum time between replies to the same sender (default: 60 minutes)
- Enabled: toggle to activate or deactivate the rule
Acceptable use policy for automation
Automation must comply with Telegram's Terms of Service. Specifically:
- Do not send unsolicited bulk messages to users who have not opted in.
- Do not automate joining groups for the purpose of spamming.
- Do not use automation to scrape user data without consent.
- Do not operate networks of accounts for coordinated inauthentic behavior.
Violations of this policy may result in account suspension and forfeiture of your subscription balance.