Embedded distribution — offering your product inside someone else's checkout, at the moment of need — is one of the fastest-growing channels going. Travel cover at flight checkout, device protection when you buy the phone, financing in the cart.
Every strategy deck about it underestimates the same thing. Everyone assumes the API is the hard part.
The API is the easy part.
What "embedded" actually demands
The promise is speed and invisibility: the customer is offered exactly the right thing at exactly the right price and accepts with one tap. No forms, no friction.
Deliver that and you win. But that one tap makes brutal demands on your back end:
- Price in milliseconds, inside the partner's checkout, no human in the loop.
- Make an eligibility decision instantly, from whatever thin data the partner passes you.
- Create the record in real time — and have it exist, correctly, in your systems immediately.
- Do this at the partner's traffic volume, which spikes unpredictably and isn't yours to control.
- Then service what you just sold like anything else — support, changes, compliance, reporting.
None of that is an API-design challenge. It's a data-and-systems-readiness challenge.
Why the API is the easy part
Building an endpoint that accepts a request and returns a quote is a week of work. The hard part is what has to happen behind it in the 200ms you have to answer.
Real-time pricing. Your pricing logic has to return synchronously, under load. If it lives in a core system designed for batch, it can't answer in checkout time — and the customer has moved on.
Instant decisioning on thin data. The partner passes a name, a destination, a date. You must enrich that against your own and external data in the moment. Thin input demands rich, fast context.
Straight-through creation. The record must be created correctly with no manual step. Every batch-oriented, human-in-the-loop assumption in your fulfilment process is a wall the embedded flow hits at speed.
It has to be a first-class record. Sold in three seconds or not, it now needs to be serviceable, reportable, and compliant like everything else.
The trap: the parallel stack
The tempting shortcut: build embedded on a separate, modern, fast stack, bypassing the legacy core because it can't keep up.
It works at launch. Then reality arrives — those records need servicing, support, renewals, and reporting alongside everything else. Now they live in a different world, with a different customer identity, and you've recreated the fragmentation problem you spend the rest of your life fighting.
The right answer isn't a parallel stack. It's a real-time-capable foundation that both the embedded channel and traditional channels draw from — one pricing service, one fulfilment path, one customer identity, fed fast enough for checkout.
What actually needs to be true
- A pricing service that answers synchronously — extracted from the batch core, callable in real time, under load.
- Real-time enrichment — take thin partner data and join it to yours and third-party data in the moment.
- Straight-through, real-time fulfilment — no batch, no manual step, record exists immediately.
- One customer identity — the embedded customer resolves to the same person as your direct customer, so you don't build a second book you can't see.
- Elastic scale — the partner's traffic isn't yours to control.
The point
Embedded distribution is a go-to-market strategy that quietly imposes a systems-modernisation requirement. You can't deliver invisible, instant, correctly-priced offers inside someone else's checkout on top of a batch-oriented, fragmented back end — no matter how clean your API is.
The teams that win at embedded won't be the ones with the best partnerships. They'll be the ones whose foundation could answer in 200ms and still treat the result as a real record.
As usual, the visible thing — the API, the partnership — isn't where the difficulty lives. It's underneath.
We build the real-time pricing, enrichment, and fulfilment foundations embedded products run on. More at IntelliBooks.
Top comments (0)