Event-Driven CRM-ERP Integration: Webhooks, Outbox & DLQ

A production guide for signed webhooks, idempotency, queues, outbox, retries and dead-letter replay.

A production guide to signed webhooks, idempotency, queues, outbox, retries, DLQ replay, ordering and observability with practical Laravel examples.

Key takeaways

Use signed webhooks for intent, not as the only source of durable truth.
Store outbound changes in an outbox table before publishing to queues.
Use idempotency keys, correlation IDs and dead-letter replay before scaling integration volume.
Connect this pattern to a commercial CRM-ERP integration service when sync reliability affects quoting, orders or finance.

Reference architecture

A reliable CRM-ERP event flow separates user actions from downstream delivery. The CRM records the state change, writes an outbox record, a worker publishes the event, and the ERP adapter acknowledges or rejects it with a traceable result.

CRM transaction -> outbox table -> queue worker -> ERP adapter -> retry policy -> DLQ replay -> reconciliation dashboard

Implementation checklist

Webhook signature middleware
Idempotency migration with unique external reference
Outbox worker with backoff table
Correlation ID in every log line

Dead-letter queue reason codes
Replay screen with payload diff
Ordering rules per entity type
Test scenarios for timeout, duplicate and partial failure

Laravel example: idempotency key

Schema::create('integration_requests', function (Blueprint $table) {
    $table->id();
    $table->string('source');
    $table->string('idempotency_key')->unique();
    $table->string('correlation_id')->index();
    $table->json('payload');
    $table->string('status')->default('received');
    $table->timestamps();
});