Magento 2 Webhooks and Event-Driven Integrations

Polling Magento’s API for changes works, but it wastes calls and lags behind reality. Event-driven integration - Magento pushing changes to your systems as they happen - is faster, cheaper and kinder to both sides. Here is how to build it reliably, given what Magento does and does not provide natively.

The Honest Starting Point

Core Magento 2 has no general-purpose outbound webhook system (Adobe Commerce’s Adobe I/O Events adds one for Commerce customers). The standard pattern on Open Source is built from pieces Magento does have: observers for the event, the message queue for delivery.

The Observer-to-Queue Pattern

1. Observer on the business event (sales_order_place_after, catalog_product_save_after, customer_save_after): does almost nothing except publish a message
2. Queue message carries the entity ID and event type - not the full entity (it may change before delivery; fetch fresh at send time)
3. Consumer loads the entity, builds the payload, POSTs to the endpoint, and records the result

public function execute(Observer $observer): void
{
    $this->publisher->publish('acme.order.created', [
        'order_id' => (int) $observer->getOrder()->getId(),
    ]);
}

This shape gives you what naive webhooks lack: retries via queue redelivery, async execution that never slows checkout, and an audit trail.

Payload Design

• Minimal, versioned payloads: {event, id, occurred_at, version} plus the entity snapshot the consumer actually needs. Receivers can always call back to the API for more
• Sign every request: HMAC of the body with a shared secret in a header. Receivers must verify it - unsigned webhooks are how data gets spoofed
• Idempotency key per event delivery; receivers should dedupe, because retries will happen

Receiving Side Discipline

If you also control the receiver:

• Return 2xx fast, process async - a slow receiver backs up the queue
• Handle out-of-order delivery: event ordering across queues is not guaranteed; use occurred_at and last-write-wins where the data allows
• Dead-letter handling: after N failures, park the message and alert - a poison message must not block the queue forever

When to Use Adobe I/O Events Instead

On Adobe Commerce, I/O Events provides managed webhooks for commerce events with retry and signing built in. If you are licensed for it, use it - replacing queue plumbing with a managed service is a good trade. The design lessons above (minimal payloads, idempotent receivers, verified signatures) still apply.

The Reliability Bar

The difference between an integration and a liability is what happens on the bad day: endpoint down for an hour, duplicate deliveries, messages arriving during the receiver’s deploy. Queued delivery, signed payloads, idempotent handlers and dead-letter alerts cover all four. Build those once and every future integration is a new observer and a new payload - an afternoon, not a project.