Build reactive integrations with Composio webhook triggers

Most integrations start by doing something: sending an email, creating an issue, or updating a record. With triggers, they can also start work when something changes.

Composio has added webhook trigger coverage for Shopify, Close, Jira, Twilio, Trello, Fathom, Kit, Calendly, Outlook, Ashby, MailerLite, LINE, Plain, and Stripe. These are recent additions to a webhook trigger catalog that also includes Slack, Notion, Asana, and Linear. Your application or agent can react to their events without a separate webhook receiver for each integration.

The triggers cover commerce, CRM, project management, recruiting, marketing, scheduling, email, support, messaging, and payments. They fire when a Shopify product goes out of stock, a Close lead changes status, an Ashby candidate moves to a new interview stage, or a Stripe payment fails.

One event flow across toolkits

Every provider handles webhooks differently. Registration, event names, payloads, and signature schemes vary. Some providers attach a webhook to an account. Others attach it to the resource being observed.

Composio handles the resource-specific registration and sends events through the same flow:

1. Connect the provider account to a user or workspace in your application.
2. Create a trigger for that connected account.
3. Receive signed events at your Composio webhook endpoint.
4. Route the event with its trigger, connected account, and user metadata.
5. Run application logic or give the event to an agent.

You write one webhook handler instead of maintaining separate receiver logic, signature code, and account mapping for every provider.

The trigger metadata includes the trigger_slug, trigger_id, connected_account_id, auth_config_id, and user_id. Use your existing user_id as the tenant or workspace key. If a user has more than one connected account, route the event with connected_account_id.

Turn events into actions

Use a trigger to start the next step in a workflow:

• When SHOPIFY_PRODUCT_VARIANT_OUT_OF_STOCK fires, retrieve current inventory and update a purchasing or fulfillment system.
• When STRIPE_INVOICE_PAYMENT_FAILED fires, retrieve the customer and subscription, create a Jira issue, and notify the support team.
• When an Ashby candidate moves to an interview stage, schedule the interview through Calendly or Outlook and update the hiring workspace.
• When FATHOM_MEETING_CONTENT_READY fires, retrieve the meeting content, extract commitments, and write follow-up activities to Close.
• When NOTION_PAGE_PROPERTIES_UPDATED fires, synchronize the changed record with a search index or knowledge agent.
• When Plain or LINE receives a customer message, classify the request and create or update the correct support task.

You can run these workflows in application code, a background job, or an agent task. The event carries the routing context, and Composio tools can run the follow-up actions.

Build for at-least-once delivery

Composio signs each webhook delivery and retries failures. Because delivery is at least once, your handler must be idempotent.

Before starting work, store the Composio event_id. If the same event arrives again, return a successful response without running the action twice. Otherwise, a retry could create a duplicate issue, send the same message twice, or repeat an update.

The API lets you create, list, update, enable, disable, and delete trigger instances.

Start with one event

Start with one event that matters to your product. Connect a test account, create the trigger, and send the event to an idempotent handler. Get that path working before you add the follow-up action.

Before you create your first trigger, read the trigger overview and the webhook subscription reference. The platform trigger guide covers idempotency and duplicate delivery. The toolkit catalog lists the events and authentication methods for each provider.