Which connectors can receive inbound webhook events?

The event trigger in the task form lists the available connectors and event types. For example, you can process an incoming Umnico message or respond to a new Bitrix24 deal. Use a scheduled task to check for new Wildberries reviews, questions, chats, and orders.

How do I run a task automatically when an event arrives?

Create a task in the app with an event trigger: pick the service and the event types to react to, or all of its events. To narrow which payloads run the task, ask the agent in chat to add filter conditions to it. When a matching event arrives, the task executes with the event as its input.

Webhooks & events

Connectors are not only called outward: many receive inbound events (a new CRM deal, an incoming message, an order status change). Those events land in a local journal and can trigger automated tasks, so you can react to what happens in an external service without polling it.

How an inbound event flows

Register the webhook URL

For services with automatic setup, such as Umnico and Wazzup, the platform registers the webhook when you connect the account. Saving the key and registering the webhook have separate outcomes. If the provider rejects registration, the connection card shows the reason and the available action. For services with manual setup, copy the webhook address from the card and paste it into the provider's dashboard.

The provider POSTs the event

When something happens on the provider's side, it POSTs to that URL. The platform checks the token in the URL and the signature if the provider signs requests, drops redeliveries, and records the event in the journal.

React

Have a saved task run automatically the moment a matching event lands.

Webhook URLs

Each connection that receives inbound events has its own random webhook URL. Treat it like a password. For manual setup, the card shows the URL to people who can manage the connection (its owner or a role allowed to manage integrations). The app reads the URL from GET /api/v1/credentials/{service}/webhook/url and the registration state from GET /api/v1/credentials/{service}/webhook/status. These endpoints require a signed-in user's session. An organization key gets 401.

With manual setup, paste the address exactly as copied. It already contains its route token. Enter API keys and provider signing secrets separately when the service asks for them.

In Megaplan, go to Settings → Applications, open the relevant app, and paste the address into the event-receiving URL field. Select the streams you need, save, and create an event in one of those streams. Megaplan documentation

For manual setup, the card says "this address has not received any events yet" until the first verified delivery. If the provider has already sent events, check the address in its dashboard.

Address held by another service

Some providers keep a single webhook address for the whole account: wazzup keeps one per API key, and the same key often already serves a customer's CRM. The platform reads such a slot first and does not overwrite someone else's address: the connector row and its card show the host events currently go to and a Replace address button. After the replacement the previous service stops receiving events, so the replacement asks for confirmation. The app does it with POST /api/v1/credentials/{service}/webhook/register and the body {"replace_foreign": true}, under the signed-in user's session; an organization key cannot call it. Wazzup cannot delete an address, so on disconnect the platform touches the slot only while it still holds its own address: it puts back the previous address if it replaced one with your confirmation, and otherwise switches its own subscriptions off.

Replacing the URL

The old URL keeps accepting events for 24 hours after rotation. With manual setup, an organization admin can issue a new URL from the connection card. The card shows when the old URL expires. Paste the new URL into the provider's dashboard before then. If you rotate the address of an automatically configured service through POST /api/v1/credentials/{service}/webhook/rotate, the platform registers the new address with the provider.

Verification and delivery

Signature. Besides the token in the URL, the platform verifies the provider's signature over the raw request body, with that provider's scheme, whenever the provider signs its requests. A request with a bad signature is rejected and never reaches the journal.
Format. JSON or application/x-www-form-urlencoded body; the body size is limited.
Answer. A delivery the platform accepted gets 2xx with {"outcome": "…"}, one word of the closed vocabulary below. A refusal is a 4xx/5xx, never a 200 with an error inside.
Answer and retries. A verified delivery is answered 200 with outcome: "received" as soon as the event is recorded; processing runs right after the answer. If processing fails, we retry it ourselves with a growing pause (from a minute up to an hour, about six hours in total), so the provider does not need to resend. A repeat of an already processed delivery id is answered outcome: "duplicate" and runs no task; a repeat of one still being processed or waiting for our retry is answered received. 503 means the event could not be recorded, and the provider should retry. 4xx is only for an unknown address, a bad signature or a body that is not JSON or a form.
Loop guard. A burst of events for one entity runs no tasks, so an agent replying into the same service does not loop.
No matching task: the event still stays in the journal, with outcome: "no_action".

outcome	Meaning
`received`	The event is recorded and will be processed right after this answer; a failure is retried on our side.
`accepted`	Matching tasks were queued.
`duplicate`	The same delivery was already processed; no task runs again.
`handled`	The connector's own handler (a messenger reply, for example) processed the event.
`handler_declined`	The connector's own handler took the event and did not process it.
`installation_processed`	A GitHub App installation event.
`no_org_context`	The address names no organization to run tasks for.
`loop_detected`	A burst of events for one entity was recognised as a loop; no task runs.
`no_action`	No task reacts to this event; it is still recorded in the journal.
`event_skipped`	The delivery carried no event the connector recognises.
`read_dropped`	The connector read the object the event names and found nothing to act on (your own reply, an empty message); no task runs.

Triggering tasks on events

A saved task can run automatically when a matching event arrives. Tasks are created in the app (or by asking the agent in chat); an event trigger is described by:

Service. The connector whose events trigger the task.
Event types. Which event types of that service to react to (for example lead.status_changed for amocrm, deal.created for bitrix24), or all events of the service instead. One of the two is required; a name the service never sends and the journal has never seen is refused on save.
Filter conditions (optional). Conditions on the provider's raw event body, each a field (a dot path such as message.chat.id), an operator (==, !=, >, <, >=, <= or contains, a case-insensitive substring) and a value. All conditions must hold; a missing field does not match. The task form does not edit them yet: ask the agent in chat to add them to the task.

Every matching event enqueues a separate task run. The task receives the event's service, event_type, entity_id, entity_type, and payload as input. For avito, max_messenger, pachca, and wazzup, incoming messages go to the agent in chat. A private telegram message goes to a task only if that task sets filter conditions.

Umnico events trigger tasks. Select message.incoming to process new messages or lead.changed.status to react when an inquiry changes status.

Webhook vs schedule triggers

A webhook trigger reacts to an external event as it happens; a schedule trigger runs on a cron cadence (minimum interval five minutes). Pick webhook when the work is a response to something that occurred, and schedule when it should run on the clock. Both are chosen when the task is created in the app.