Case study
Two-way partner integration for an insurance core
Context
The insurer sells through partners: e-commerce platforms, banks, and brokers, each with their own system and their own idea of what an API should look like. The core policy platform was never built to face outward. Every partner submission arrived as a file or an email, and someone in operations typed it into the core by hand.
I took the partner channel end to end: the architecture, the API contract, the code, and the conversations with the business units on both sides. Not only IT. The partner's commercial team and our underwriting team had to agree on what a valid submission even was.
Problem
Manual entry is slow, and slow is expensive when a customer is waiting for proof of cover. It also hides errors: a mistyped plate number surfaces at claim time, months later, when it is someone's problem and nobody's fault.
Two constraints shaped everything. The core platform could not be rewritten, because the whole business runs on it. And partners were not going to build to a bespoke spec each time, because we were the smaller party in most of those relationships.
Options considered
One API per partner. Fastest to ship the first one, then it compounds: every new partner is another codebase and another place to fix the same bug. Dropped.
Let partners write to the core directly. Rejected for the obvious reason. The core has no idea who is calling and no way to turn back a bad payload without a human reading it.
One gateway, two patterns. Chosen. Everything a partner sends passes through a single service that validates, maps, and then talks to the core the way the core expects. Partners are classified into two flows, not fourteen.
What I built
One-way, B2C. The partner sells, submits, and the policy is created in the core with no human in the middle. Good enough where the partner owns the customer relationship and only needs a policy number back.
Two-way, B2B. Same intake, and the issued policy document goes back to the insured automatically, in a format identical to the one the core produces. This is the part partners actually wanted. Their customer gets the real document, not a screenshot of a spreadsheet.
Beside the return path I built a monitoring dashboard: every submission, its status, and where it stopped. Internal users read it instead of re-keying. When a partner asks whether a submission went through, the answer is on a screen rather than in someone's inbox.
Result, and what I would keep
The B2B channels no longer touch the core by hand at all. Operations moved from data entry to exception handling, which is the work that actually needs a person.
What I would keep for the next one: classify partners into a small number of patterns before writing any code, and treat the document that reaches the customer as part of the integration rather than an afterthought. That last part is what made partners sign.
NextA retail insurance portal tied to core, finance, and payments →