Events & webhooks

Comers Events lets external systems react to supported business activity without requiring a dedicated native connector for every application.

A registered webhook can receive selected Comers events and pass them into an automation platform, integration service, or another system that needs to continue the workflow.

flowchart TD
    C[Business activity in Comers] --> E[Comers Event]
    E --> S[Event subscription]
    S --> W[Webhook delivery]
    W --> A[Automation or integration]
    A --> X[External system]

Events are business signals

An event represents something that happened in a Comers business domain.

Depending on the currently available event catalogue, events can concern areas such as Orders, Shipping, Messages, Products, inventory, Support, or other operational domains.

The catalogue determines which events are available for subscription. Do not assume that every change in every module is exposed as an event.

Webhook subscriptions

A subscription connects selected supported events with an external destination.

This allows different workflows or systems to subscribe independently to the activity they need.

For example, one workflow can react to a Support event while another handles a Shipping event without requiring both consumers to share the same destination or lifecycle.

Delivery and retries

Webhook delivery is designed for operational integrations rather than best-effort notifications.

A temporary destination failure can cause Comers to retry a delivery. If delivery cannot be completed after the supported retry process, the failed delivery can remain available for investigation or replay according to the available integration tooling.

Because delivery is designed to tolerate retries and replay, consumers should treat events as at-least-once delivery. A workflow should therefore be safe if the same business event is received more than once.

Where the event envelope exposes a stable event identifier, use that identifier when deduplication is required.

Verify incoming deliveries

Webhook consumers should verify that an incoming delivery actually came from the Comers installation they trust.

Comers provides signed event delivery for integrations that support verification. The concrete verification mechanism belongs to the integration contract and should be handled by the receiving connector or application.

Do not place verification secrets or credentials in workflow notes, screenshots, source code, or general documentation.

What webhooks are good for

Events and webhooks are useful when another system should react after something happens in Comers.

Typical patterns include:

• starting an external automation after a supported Order event,
• forwarding selected operational events into another business system,
• triggering notifications or internal workflows,
• enriching an event with data from another application,
• connecting Comers with a customer-specific integration service.

The webhook is the trigger. What happens afterwards belongs to the receiving workflow or application.

Native integrations and webhooks solve different problems

A webhook does not replace a native marketplace integration.

Native integrations are used when Comers needs deep provider-specific behavior, synchronization, or first-class operational workflows.

Events and webhooks are better suited to extending Comers into the wider customer ecosystem.

flowchart TD
    N[Need an external connection] --> Q{Deep provider-specific commerce behavior?}
    Q -->|Yes| I[Native integration]
    Q -->|No| E[Events / webhooks / automation]
    I --> C[Comers operating model]
    E --> C

Automation platforms

Webhook events can be consumed by automation platforms that can continue the workflow into other applications.

Comers has a dedicated n8n integration for receiving Comers Events in n8n workflows.

For the wider integration model, see Integrations.