Actions

Actions are what the bot executes when a reaction fires. A reaction can have multiple actions; they run in order from top to bottom. Add them with the Add action button in the Actions section of the editor. Actions share data through the execution context (ctx) and user parameters: see Substitutions and formulas.

Messages and replies

• Send message: the primary action: assembles a response from blocks (text, photo, file, delay, AI, reaction call), adds inline buttons, menus, and dialog steps. See Messages and buttons for details.
• Save message: stores the incoming message text in a user parameter.
• Forward: forwards the incoming message to specified chats (with an optional topic ID).
• Notification: sends a notification to service chats with data about the user, chat, and message text.
• Menu button: changes the Telegram menu button (setChatMenuButton) without restarting the bot: default, command list, or a Mini App with text and URL (substitutions work). Scope "this chat" only works in a private chat with the subscriber who triggered the reaction — in a group or any other conversation kind the action fails; scope "all chats" changes the bot-wide default for every chat with no button of its own, and cannot sit inside a loop. Channels other than Telegram skip the action silently.

User: labels and parameters

• Edit labels: adds and/or removes subscriber labels.
• Edit parameters: sets, deletes, or increments user parameter values.

Moderation

• Delete received: deletes the incoming message (optionally all of the user's messages, with a delay).
• Delete sent: deletes the bot's messages (from this reaction or all in the chat, with a delay).
• Change rights: mute / unmute / ban / unban / restrict rights for a member, temporarily or permanently; for restriction, specific rights are selected.
• Important reaction (color): marks the conversation with a color for the operator.

Data and collections

• Create record: adds a row to a collection; with a deduplication key it acts as an upsert (no duplicates).
• Update records: modifies rows matching a filter.
• Find records: reads rows into the context as an array (for iteration).
• Delete records: removes rows matching a filter.
• Loop over list: iterates over an array from ctx and runs nested actions for each element: totalling orders, writing every element into a collection, calling an external service per row.

A loop is not for mass sending: one event may send at most 50 messages, while a loop takes up to 500 elements. Mass delivery belongs to Broadcasts and Campaigns, which have their own pacing and accounting. Details in "The budget of one event" below.

For more on collections, see Collections and data.

External requests

• Web request: an HTTP request (GET/POST/PUT/DELETE) with headers, body, success codes, timeout, and retries; the response is saved to a parameter or ctx via JSONPath; can run asynchronously and trigger reactions on success or error. The Idempotency-Key header is set by the platform itself and carries the same value when the same step is retried (a header of your own with that name is replaced): the receiving side can use it to drop duplicates.
• Fetch URL: downloads a page and saves its readable text to ctx (for subsequent processing or AI).
• Source request: reads data from a connected connector (REST / OzmaDB) into ctx.
• Write to source: writes data to a connector (POST/PUT/DELETE).

For sources and keys, see Sources and keys.

AI and computation

• AI: calls a language model: prompt, save the response to a parameter or ctx, optional JSON schema for structured extraction, send the response to the user. See AI responses.
• Compute: computes a value in one of three modes, exactly one per action: "Formula" (a short expression, expr), "Decision table" (rules of the form "when → then", first true wins, rules), or "Advanced formula" (the full language with lists, JSON, and hashes, formula). The result is saved to ctx and/or a parameter. See Formulas.

Logic and scenarios

• Chain reaction: triggers another reaction by name.
• Next reaction: passes control to the next matching reaction in the list.
• Run scenario: starts a step-by-step wizard (flow). See Scenarios.
• Request approval: sends an approval card to an approver; "approve" / "reject" buttons trigger configured reactions.
• Transfer to operator: moves the conversation to the operator inbox. See Chats and operators.

Integrations

The GetCourse, Google Sheets, and Google Drive actions connect through the corresponding integrations (see Integrations). In the reaction builder these actions are marked as "coming soon": for now, use them via integration settings, web requests, or AI. Universal delivery to external services is available through the Webhook integration and the Web request action.

The budget of one event

One inbound event: a subscriber's message, a button press, a trigger firing: spends an event budget. It is shared by every piece of work that event caused: the reaction itself, chained reactions, nested loops, and asynchronous web requests that keep running after the reply. The budget exists so that one mistake in a reaction (or one hostile input) cannot occupy workers shared by every bot.

Three boundaries:

One loop is bounded separately: up to 500 elements per pass. If the array is longer, the extra elements are simply not processed, and the reaction card does not show it: so do not rely on a loop where the whole list must be processed.

Why 50 messages but 500 elements

This is neither a typo nor a forgotten setting. It is the boundary between two different things.

A reaction answers one person's action. Fifty outbound messages for one inbound message is already generous.

A broadcast delivers to many. It has its own pacing, its own pauses, its own accounting of what was sent, and a pause button. See Broadcasts and Campaigns.

So a 500-element loop with a message send inside is not a broadcast: it is a truncated one: the first 50 messages go out and the remaining 450 are refused. That is the intended answer, not a fault. If you need to send to a list, use a broadcast.

What is counted is outbound messages, not actions. A reply made of several blocks (text, photo, file) spends one per block. If the next reply does not fit into the remaining budget, none of it is sent: better no message than half a message.

How to tell you hit the budget

The refusal shows up in the reaction card inside the subscriber's dialog (People → the dialog): among the steps there is an error step about the event budget, and it names which budget ran out: actions, sends or deadline. (That step's title comes from the engine and is written in Russian in every interface language.)

What the refusal is not in: it does not appear in an API response and it never reaches the subscriber. If the reaction was started through the API or a web request, that answer is an ordinary success: the call itself was accepted; it is work inside it that was refused. The reaction card is the only place to see it.

A refusal does not break the loop: it keeps iterating over the remaining elements, and each of them is refused the same way. So the card holds many error steps, one per element that did not fit, and the reaction itself finishes with an error.

What to do instead

• You need to send to many people: Broadcasts or Campaigns. They carry no event budget: they are a separate, paced process with their own accounting.
• You need to process a large list without sending (write, total, synchronise): a loop is the right tool, but remember the 500 elements per pass: narrow the selection with a filter or a collection limit.
• You need nested loops: multiply: an outer 100 by an inner 100 is 10,000 actions, twice the budget.
• A reaction runs into the 5 minutes: it is almost always external calls. Make the Web request asynchronous and continue in a separate reaction on success or error.

What's next

• Messages and buttons: the response and dialog builder.
• Substitutions and formulas: variables in text and logic.
• Broadcasts: mass delivery, when a loop is not the answer.