Integrations

External services connect to a scenario in two ways: as dedicated trigger/action nodes right on the scheme (built-in integrations), or through the ActivePieces catalog of ready-made integrations.

Built-in integrations

• Telegram Bot API. The “On message” trigger starts the scenario on every new message to the bot; the “On command” trigger starts a separate trigger function for one command (/start, /help, …) — when both are bound, a matching command goes only to its own function. “Send message” replies on the bot’s behalf, and “Ask question” sends a question with inline-keyboard buttons and waits until the user taps one (optionally with a timeout branch), continuing down the branch of the pressed button. A photo, document, voice message, audio or video attached to an incoming message is resolved into a File automatically, and “Send file” delivers one back as an attachment. Credentials (the bot token) are stored separately for the dev and prod environments and encrypted at rest. Locally the engine long-polls Telegram; once a public address is configured it switches to webhooks automatically.

• OpenAI-compatible models. The “Call AI” action sends a chat-completion request to the selected model and returns text, optionally with file attachments (e.g. an incoming Telegram photo) attached to the prompt; a separate “AI Choice” node asks the model to pick one of a set of predefined options with structured data — handy for branching a scenario off the model’s answer. “Call AI (image)” generates an image and returns it as a file, and “Call AI (transcribe)” turns an audio file into text. The API base URL is configurable, so this works with more than just api.openai.com — Azure OpenAI, local servers like llama.cpp, and any other compatible provider.

• HTTP request. A generic outbound call to any HTTP API: method, URL, headers and body are given as expressions, and the result is stored in a variable — including, when the response is binary, as a file rather than decoded text. No credentials of its own are needed — authorization is simply written into the request headers.

• Webhook. A generic inbound trigger: each trigger function gets its own URL, and calling it (a POST request) starts the scenario, passing the request body as input.

• Schedule. A timer-based trigger — a fixed interval or a cron expression — that starts a scenario on a recurring basis with no external service or credentials involved. See Schedule triggers for the full picture (cron builder, dev/prod behavior, overlap handling).

• Files. Every scenario can create, read, publish and pass around files — a reference value, never raw bytes in the scenario’s own state — backed by the platform’s own object storage, with per-user quotas and automatic expiry. See Files for the full picture.

• Databases. A single connection string connects a scenario to a Postgres or MySQL database (SQLite too, for local development); “Sync structure” makes the editor know its tables, so select/insert/update/delete actions are typed per table with Monaco completion, plus a small operator DSL for filtering and a raw-SQL action for anything else. See Databases for the full picture.

• Tasks. A human task pauses a scenario until the project owner resolves it from a Tasks page — approve/reject (or any custom set of options), each with its own typed answer, plus an optional timeout branch. No credentials needed — the task is always addressed to whoever owns the project.

• Media. Resize/convert an image, trim/concatenate/thumbnail/transcode a video, extract or convert audio — all powered by ffmpeg on a dedicated service, working on files in and out. No credentials needed. See Media for the full catalog of operations.

Russian services

Built-in integrations for services in demand on the Russian market. Each is a separate vendor in the project’s Integrations document, with its own credential (stored separately for dev and prod, encrypted at rest).

• 1С (OData). “Get records” reads a collection (e.g. Catalog_Контрагенты) from a 1С:Enterprise database through its standard OData interface, with an optional OData $filter. Credential: the OData base URL (…/odata/standard.odata), a 1С user and password. Needs platform 8.3.5+ with the standard OData interface published; read-only for now.

• Bitrix24. The “Event (outgoing webhook)” trigger starts a scenario on any portal event (ONCRMLEADADD, ONCRMDEALUPDATE, …); the event name is in event.event, so one function can branch on it. Each bound trigger function gets its own URL — paste it into the portal’s outgoing webhook settings; the credential is that webhook’s application_token, which every call is checked against. There are no actions: call the Bitrix24 REST API through HTTP request with an incoming-webhook URL.

• amoCRM. “Create lead” (name and price). Connected with OAuth2: pick amoCRM in the integrations list and click “Connect”. It appears only once an administrator has entered the amoCRM app’s keys on the “OAuth credentials” page (see administration). amocrm.ru accounts only.

• ЮKassa. The “Payment/refund event” trigger starts a scenario on a notification such as payment.succeeded, payment.canceled or refund.succeeded. Notifications are not signed, so the engine re-reads the payment or refund from the ЮKassa API with the shop’s credentials and passes on only the confirmed object. Credential: Shop ID and secret key; paste the trigger function’s URL into the merchant cabinet’s notification settings. To create a payment, use HTTP request (Basic auth plus an Idempotence-Key header).

• Диадок (Kontur Diadoc). “Get documents” lists the documents of an organization’s box (up to 50, metadata only). Connected with OAuth2 using your own Kontur app (redirect URI https://<your backend host>/oauth2/callback/diadoc; Client ID/secret, then “Connect”) plus the box ID. Sending and signing documents is not supported — it needs a qualified e-signature.

• МойСклад, Ozon Seller API, Wildberries Seller API. One “Call method” action each, with a picker over the vendor’s whole API (about 1 200 methods for МойСклад, 470 for Ozon, 270 for Wildberries); the method’s parameters are typed, so the editor completes them. Credentials: a МойСклад access token; Ozon Client-Id and Api-Key; a Wildberries API token (valid 180 days, renewed by hand in the seller cabinet). Vendor rate limits are handled by automatic retries.

• GigaChat and YandexGPT. “Chat completion” sends a prompt and stores the text answer in a variable. GigaChat: the authorization key from Sber’s developer cabinet and the API scope (personal or business); YandexGPT: a service account API key and the folder ID. The model name is typed by hand (e.g. yandexgpt/latest).

• Т-Банк (sandbox). “Account statement” reads a business account statement from T-Bank’s public sandbox, for trying out a flow; working with a real account is not supported yet.

ActivePieces — a catalog of ready-made integrations

For services that don’t yet have a dedicated built-in integration, an adapter on top of the open-source

ActivePieces

library is used. It runs as a separate service, isolated from the rest of the engine — third-party integration code runs in its own process and has no access to the core system — and exposes a curated list of ready-made actions. Currently included (62 services):

• Messaging — Slack, Discord, Mattermost, Microsoft Teams;

• Google Workspace — Google Sheets, Gmail, Google Drive, Google Calendar, Google Forms;

• Email & marketing — SMTP, IMAP, SendGrid, Resend, Mailchimp, ActiveCampaign, Klaviyo, Sendinblue (Brevo);

• Project/task management & CRM — Notion, Trello, Jira Cloud, Todoist, Linear, ClickUp, HubSpot, Salesforce, Pipedrive, Zoho CRM, Close, monday.com, Asana, Wrike;

• Support & helpdesk — Zendesk, Freshdesk, Intercom;

• Developer tools — GitHub, GitLab;

• Data & storage — Airtable, Postgres, MySQL, Amazon S3, Dropbox, MongoDB, Box;

• Forms & scheduling — Typeform, JotForm, Calendly;

• Communication & video — Zoom, Twilio;

• E-commerce — Shopify, WooCommerce;

• Payments & accounting — Stripe, Razorpay, Paddle, QuickBooks, Xero;

• Documents & eSignature — DocuSign, PandaDoc;

• Analytics — Mixpanel, PostHog;

• Content & social — WordPress, RSS, YouTube.

This mechanism supports basic auth, arbitrary custom auth fields, and full OAuth2 (an authorization popup plus automatic token refresh) — so it can connect services that need OAuth2 even before the built-in integration framework supports it directly. For an OAuth2 service, the OAuth2 client (client ID/secret) is registered once by the deployment’s admin, in the Admin app’s “OAuth credentials” page — not per credential. A service an admin hasn’t enabled there doesn’t appear in “add integration” at all; once enabled, connecting an account is just a “Connect” click, no client ID/secret to paste in. See Administration for the full walkthrough. Some of the services above declare more than one authentication method (e.g. Slack, Notion, HubSpot, GitHub); in those cases the adapter picks the one best suited to a self-hosted deployment (typically a static token) rather than requiring a vendor-registered OAuth2 app.

Most actions above are typed forms generated from each service’s own field definitions. A few services (including Typeform, JotForm, Calendly, and Box, plus a generic “custom API call” action present on nearly every service) only expose fields whose shape the vendor computes at runtime — for those, the field is a single free-form expression (an authenticated HTTP passthrough to that vendor’s API) rather than a typed form, and there’s no live suggestion of the exact keys the vendor expects.

What’s next

The list of built-in integrations keeps growing. Most of the Russian services above start with a few core actions or a single trigger; more actions (writing to 1С, amoCRM contacts and tasks, sending documents through Диадок) are planned.