Telegram automation workflows, specified by trigger and mechanism
This library documents Telegram automation workflows one at a time. Each entry states the trigger, the condition, and the action, names the mechanism that carries it, and lists the rights and limits involved. An entry describes what can be built for a client. It is not a download, and no entry bypasses a Telegram limit.
A workflow is a small machine with three parts. A trigger is the event that starts it. A condition decides whether anything should happen. An action is the call that changes something in Telegram or in a system connected to it. Every entry in this library is written in that order, because that is the order in which a workflow either works or fails.
Each entry answers the same five questions:
- Which event starts it? A command, a button press, a new member, a payment, a set time, or a call from an outside system.
- Which mechanism carries it? A bot on the Bot API in most cases, a built-in admin setting where no code is required, or a user-account client where nothing else can do the job.
- Which rights does it require? A bot that posts to a channel has to be an admin of that channel. A bot that deletes messages requires the matching admin right in the group. The entry lists each right, so you can grant only what is needed.
- Which limit constrains it? The per-chat pace, the group pace, and the broadcast pace published in Telegram's bot FAQ, or a flood wait on the user-account side.
- What does it not do? The boundary of the workflow, stated before you ask for it.
The entries are grouped by family: bots and forms, scheduled posting, group moderation, broadcasts to bot subscribers, integrations and webhooks, and data exports. A family is a convenience for browsing. The mechanism is what determines the design, so two entries in different families can share most of their structure when both run on the same kind of update.
Two reading notes apply to the whole library. First, an entry is a specification, not a product page. It explains how the workflow operates so that you can judge whether it fits your channel, group, or bot before you contact anyone. Second, an entry carries the date on which its platform facts were checked. Telegram revises its developer pages, and the current text of Telegram's bot documentation takes precedence over anything written here.
No entry describes messaging people who did not start a bot or join a chat, and no entry describes a way to avoid a flood limit. Requests of that kind are declined, as the boundary list on the home page sets out.
Which workflows are documented so far?
- No workflow has been documented yet. The first specification will appear in this slot. Until then, the contact page accepts a brief for any workflow.
What should you know about this library?
Are these Telegram workflow examples free to copy?
The descriptions are public, and you may build from them yourself. An entry contains the logic and the limits, not the finished code. The code is written per client, because rights, hosting, and connected systems differ in each case.
Does every workflow require a bot?
Most do. A few jobs are covered by settings that Telegram's apps already give an admin, and the entry says so when that is the case. A user-account client is specified only when a bot cannot perform the job and the account belongs to you.
Can two workflows run on one bot?
Yes. One bot can serve several workflows, since each one reacts to its own kind of update. The shared constraint is pacing: every workflow on the bot sends through the same queue and counts toward the same limits.
Why does each entry list what the workflow does not do?
A stated boundary prevents a build that fails review later. If the result you need lies outside what the mechanism or Telegram's rules permit, it is better to learn that from the entry than from an error.
This library is published by an independent build service. Telegram has not reviewed or approved these specifications and has no connection to the service.