Event-Driven CRM Integration

From conversational request to a validated backend action.

1. 01

   Voice platform sends a signed outcome webhook

2. 02

   Receiver validates signature and replay window

3. 03

   Event enters an idempotent durable inbox

4. 04

   Tenant-scoped CRM record is updated

5. 05

   Transient errors enter a retry/outbox queue

6. 06

   Operator can reconcile missing and duplicate events

What I built

• Implemented HMAC signature and timestamp verification for event ingestion.
• Implemented tenant-scoped event fingerprints, duplicate responses and explicit conflict rejection.
• Implemented a simulated downstream outage with queued events and a reconciliation endpoint.

The actual trust boundary

Webhook callers require verification, tenant scope and a bounded replay window. Never accept a tool-generated tenant ID as authority.

The model can propose a tool call; the executor independently validates the principal, resource and side effect. I deliberately keep that boundary out of the prompt.

Failures I tested and designed around

• Duplicate event ID must not apply another write.
• Same event ID with a different payload must be rejected.
• A CRM outage must leave a recoverable queued event.
• Cross-tenant updates must be denied before the CRM call.

The operational tradeoffs

These are the constraints that shaped the API boundary. Customer infrastructure and internal metrics remain private.

• Webhook authenticity depends on provider-specific signature verification, a replay window and credential rotation; an unsigned tenant field provides no authority.
• At-least-once delivery needs durable tenant-scoped inbox/outbox state, idempotent claims, payload fingerprints and reconciliation after process failure.
• A successful HTTP receipt is not proof a CRM was updated; delivery, application and reconciliation have separate statuses.