Multi-System API Integration

The Problem

Lead and quoting data lived in four separate systems: a CRM for collecting leads, a rater for managing quotes across carriers, an intake provider for entering client data, and OneDrive for policy documents. None of them talked to each other. Agents spent a combined 18 hours per week manually re-keying data between systems. The process introduced errors at every handoff, ran on a two-hour lag, and meant that neither clients nor account managers could get an accurate status on any active quote.

The 8.8% cross-system error rate was not an abstraction. It was producing incorrect quotes sent to clients, follow-ups that fired against stale data, and binding requests submitted before underwriting information had been confirmed. The escalations the team had normalised it as just part of the job.

The Approach

The instinct on integrations like this is to start wiring APIs. We pushed back and spent the first two weeks mapping every data flow first: what moved, when, in which direction, and what happened when it failed. That mapping revealed that three of the manual reconciliation steps existed specifically to paper over failures nobody had documented. In some cases the rater and CRM held conflicting quote statuses, or the intake provider received a bind request before the client’s underwriting data had been confirmed.

The integration layer we built is event-driven rather than scheduled-batch: a new lead in the CRM triggers a webhook that propagates to the rater for carrier quote initialisation and to the intake provider for data pre-fill, all within a single coordinated flow. Every message is persisted before processing; failed deliveries go to a dead-letter queue with alerting rather than disappearing silently. The exception queue agents monitor now sees roughly 12 events per week. Compare that to 18 hours of manual reconciliation across four tabs.

The Solution

An event-driven integration layer connecting the CRM, rater, intake provider, and document store. Our goal was to replace manual data re-entry with automated, real-time propagation across all four systems.

• CRM-triggered lead events: a new or updated lead in the CRM fires a webhook that initiates downstream actions in the rater and intake provider automatically.

  Mitigates: agents copying the same information into four different systems by hand. That’s 18 hours a week of work that added no value and introduced errors at every step.

• Carrier quote initialisation: the rater receives structured lead data and opens a quote request without agent intervention.

  Mitigates: clients waiting up to two hours for a quote to appear after their details were entered (long enough to move on to a competitor).

• Intake provider pre-fill: client data from the CRM is pushed to the intake provider so agents begin from a populated form rather than a blank one.

  Mitigates: the same client information typed in two places, with the two versions quietly drifting apart.

• Persistent message queue with dead-letter alerting: every event is stored before processing; failures surface in an exception queue with immediate alerts rather than disappearing silently.

  Mitigates: failures that vanished without a trace, only surfacing when a client received an incorrect quote or a binding request went through before underwriting was confirmed.

• Exception dashboard: agents have a single view of the small number of events that require manual review each week.

  Mitigates: treating every data discrepancy as normal manual work, with no way to distinguish routine flow from something that genuinely needed attention.