The partnership is signed, the integration is not
A retailer, a travel platform, a lender or a marketplace wants to offer your insurance at their checkout. The commercial team signs them. Then engineering looks at what is needed: the partner wants to show a quote inside their checkout, bind at purchase, collect payment themselves or not, receive documents to send on, and get a monthly statement of sales and commission.
Your first two partners were integrated as bespoke projects. One calls a set of endpoints written for them; the other sends a daily file. Neither integration can be reused cleanly for the third. So the new partner starts another project, and the launch date slips while the commercial team waits.
Why integrations are rebuilt each time
Early embedded deals are usually won by saying yes to whatever the partner needs. The result is a set of one-offs.
- Each partner has its own endpoints or file formats.
- Product configuration, such as which covers are offered and at what price, is hard-coded per partner.
- Payment arrangements differ: some partners collect, some redirect to you.
- Commission and reporting are calculated separately for each partner.
- There is no sandbox, so partner developers test against your live system or not at all.
The cost of bespoke integrations
Each new partner takes engineering time you do not have, delays revenue, and adds another integration to maintain. Changes to your product have to be made in several places. Partner statements are built by hand. The commercial team cannot promise a launch date. What products you can offer through which partners, and on what terms, is for your agreements and capacity providers; the engineering should not be the bottleneck.
One partner API, configured per partner
What we build is a single integration that every partner uses, with the differences held as settings.
- A partner API for quote, bind, documents, changes and cancellations, backed by your rating service and policy administration system.
- Each partner has a configuration: which products, which covers, pricing adjustments your pricing team approve, branding on documents and commission terms.
- Payment options are configurable: the partner collects and remits, or the customer pays you directly through a hosted page.
- A sandbox with test data lets partner developers build and test without touching your live system.
- Documentation and example requests are published for partner developers.
- A partner dashboard shows each partner their sales, cancellations and commission statement, and exports for their finance team.
- Webhooks notify partners of events such as cancellations or claims so their systems stay in step.
| Partner need | Handled by |
|---|---|
| Show a quote in checkout | Quote endpoint with partner configuration |
| Bind at purchase | Bind endpoint, policy created in your system |
| Documents to the customer | Document endpoint or direct email, with partner branding |
| Monthly statement | Partner dashboard and export |
| Stay in step on changes | Webhooks |
Existing bespoke integrations can be moved onto the partner API over time, or left as they are if they work.
The next partner
The differences between partners do not disappear; they move into configuration. One partner wants the customer to pay you directly on a hosted page, another collects the premium in their own checkout and remits monthly. One wants documents in their own branding, another wants you to email the customer. Each of those is a setting on the partner record, reviewed by your operations team, instead of a branch in the code that only one engineer understands.
The commercial team signs a partner. Operations create a configuration for them. Their developers get sandbox keys and documentation. Your engineers answer questions rather than build. When the partner is ready, the configuration moves to live. Statements and commission come from the dashboard from the first month.
Is partner onboarding stuck in engineering?
- Each partner has its own endpoints or file format.
- New partners wait months for integration.
- Partner developers have no sandbox.
- Partner statements are built by hand.
- Product changes need updating per partner.