CRM Synchronization Automation: A Retry Never Creates a Second Contact

The obvious way to sync a conversation into a CRM is to call the CRM's API right there in the conversation flow and wait for a response before replying to the customer — and the obvious way this goes wrong is that CRM APIs are not always fast, and are sometimes down entirely. A synchronous integration built this way makes the customer's actual experience hostage to a third-party system they have never heard of, and a naive retry on top of that same synchronous call risks creating a second contact record in the CRM every time a request that actually succeeded looks, from the caller's side, like it might have failed.

Building a synchronous "call the CRM right now" integration is the fastest thing to ship, and its cost — a customer-facing conversation now depends on a third party's uptime and latency — often is not obvious until that third party actually has a bad day in production. Building real backoff and a real anti-duplicate guard on top of an async queue is meaningfully more work than a simple insert-and-forget, so it tends to get skipped unless a duplicate-contact incident or a CRM outage has already made the cost of skipping it concrete.

Three specific moments in a conversation's lifecycle enqueue a sync event: the start of a new conversation enqueues a "create contact" event carrying the customer's name, email, phone and channel; an AI-generated reply worth logging enqueues an "add note" event carrying the reply text; and a hand-off to a human enqueues an "escalate deal" event. Enqueuing is a simple insert into a dedicated sync-log table with status "pending," and it is built to never throw — a database failure at this exact point logs a warning and returns null rather than raising an exception that could interrupt the conversation the customer is actually having. A separate worker claims pending and due-for-retry rows through a dedicated Postgres function built specifically for atomic claiming, so multiple worker instances never process the same row twice, then calls the appropriate provider's implementation for that specific event. Before writing a follow-up note or deal to the CRM, the worker persists the resolved contact's id back onto the sync-log row — specifically so that if the external write itself succeeds but the final "mark as done" step then fails on a network blip, a retry reads that already-recorded id and reuses the existing CRM contact instead of creating an orphaned duplicate. A failed attempt is retried with real exponential backoff — 30 seconds, then 2 minutes, then 10 minutes, then 30 minutes, then 2 hours — across up to five total attempts, each one recording the specific error message, before the row is marked permanently failed rather than retried forever. An admin surface lets a team see every sync event's status, filtered by connection and status, alongside a full OAuth connect/test/disconnect flow per CRM. Critically, each of the four implemented providers — HubSpot, Salesforce, Zendesk and Pipedrive — is registered at startup only if that specific provider's own OAuth client id and secret are actually present in the environment; without them, that one provider is simply omitted from the registry, its admin routes report a clear "not configured" state, and the sync worker has no valid connection to act on for it. A fifth name appears in the underlying type system as a placeholder for a future integration but has no working implementation behind it today.

A new conversation starts and enqueues a "create contact" event for a connected HubSpot account. The worker claims it, successfully creates the contact in HubSpot, and immediately writes that new contact's id back onto the sync-log row — then the connection drops for a moment right as it tries to mark the row "ok."

The row is picked up again on the next retry cycle. Because the contact id was already persisted in the prior attempt, the retry logic sees an existing id, reuses that same HubSpot contact rather than calling "create contact" a second time, and completes the remaining step cleanly. The CRM ends up with exactly one contact for this customer, not two, despite the mid-process network drop.

A customer conversation never slows down because a third-party CRM happens to be having a slow moment — the two are structurally decoupled. A transient failure gets a real, escalating series of retry attempts instead of one quick attempt and silence, and the specific reason for each failure stays visible rather than disappearing. And a network hiccup during an otherwise-successful sync no longer risks littering the CRM with duplicate contacts for the same customer.

A team using a CRM outside the four implemented providers (HubSpot, Salesforce, Zendesk, Pipedrive) will not find a working integration today — the fifth name present in the type system is a placeholder for future work, not a usable connector, and there is no generic/custom-CRM adapter available yet.

Calling the CRM directly inside the conversation flow ties the customer's experience to a third party's uptime and turns a routine retry into a duplicate-contact risk. Centriu Synapse's queue-and-worker design removes the CRM entirely from the customer-facing path and replaces a naive retry with one built specifically to reuse an already-created contact rather than create a second one.