Every embedded insurance platform offers roughly the same three ways in: a hosted white-label flow, a drop-in widget, or a full API build. How to pick the right depth for your team — and when to change it.
Strip the branding off any embedded insurance vendor's docs and you find the same three integration options: a hosted white-label journey you link out to, a widget you drop into your page, and a raw API you build a native experience on. The choice is not about which is best — it is about how much of the insurance experience your team should own, given your traffic, your engineering capacity and how central insurance is to your product. This guide gives you the honest trade-offs of each depth and a checklist for choosing.
The short answer, if you want one: start at the shallowest depth that lets you validate demand, and only go deeper when the funnel data proves the extra conversion is worth the extra ownership. Teams that start with a full API build before they know their attach rate are optimising a number they have not measured yet.
Depth one: white-label — their flow, your logo
In a white-label (sometimes called hosted or redirect) integration, the customer leaves your interface — usually via a link or handoff screen — and completes the quote and purchase in a flow the insurance platform operates, skinned with your brand. Your engineering work is minimal: pass context in the handoff, receive the outcome back.
- Strongest at: speed to launch, compliance simplicity, and products with genuinely complex flows (multi-step medical questionnaires, document uploads) that you do not want to rebuild.
- Weakest at: conversion and continuity. Every handoff sheds users, and the experience is visibly not yours — fonts, microcopy and error handling belong to someone else. You also learn least: the funnel inside the hosted flow is a black box unless the vendor shares its analytics.
- Right for: validating a new insurance category, small teams, low-frequency or high-complexity products, and situations where your platform's own checkout cannot legally or technically host the sale.
Depth two: widget — their component, your page
A widget (embed, SDK component, iframe) renders the offer and purchase flow inside your page, but the component itself is built and maintained by the platform. You control placement and surrounding context; the vendor controls what happens inside the frame.
- Strongest at: the ratio of effort to outcome. The customer never leaves your page, the offer sits at the natural moment in your journey, and updates to the flow ship without your releases. Most compliance-sensitive rendering — disclosures, document links, consent language — arrives correct by default because the vendor maintains it.
- Weakest at: design integrity and edge cases. A component styled to approximate your design system is never quite your design system. Deep customisation requests accumulate until you are negotiating UI changes with a vendor roadmap. Mobile webviews, content-security policies and page-performance budgets all need testing.
- Right for: most platforms, most of the time. It is the default depth for a reason: real conversion, bounded engineering, and someone else on the hook for keeping the flow compliant.
Depth three: API — your experience, end to end
A full API integration means your team builds the entire customer experience — offer presentation, data collection, quote display, payment, documents — against the platform's endpoints for quoting, binding and policy management. The insurance machinery stays with the licensed layer; every pixel is yours.
- Strongest at: conversion, coherence and learning. The offer becomes indistinguishable from the rest of your product; you can pre-fill from data you already hold, test any variant you can imagine, and see your entire funnel in your own analytics. At high traffic volumes, single-digit conversion gains from native UX can dominate every other economic lever.
- Weakest at: total cost of ownership. You now own an insurance UI: disclosure placement, wording updates when products change, error states for declined risks, renewal journeys, and the regression testing that comes with all of it. Compliance review shifts partially onto your releases — the licensed layer still governs what must be shown, but you control whether it actually renders.
- Right for: platforms where insurance is a strategic revenue line with proven attach, teams with real frontend capacity, and products where the transaction data you hold enables a meaningfully shorter flow than a generic one.
The trade-off in one view
- Time to launch: white-label days, widget days-to-weeks, API weeks-to-months.
- Conversion potential: API highest, widget close behind when placement is good, white-label lowest.
- Engineering ownership: API highest by far; widget low; white-label near zero.
- Compliance surface you personally maintain: API largest, widget small, white-label smallest.
- What you learn about your funnel: API everything, widget most things, white-label little.
Note what is not on the list: revenue share. Integration depth usually does not change the commercial split — it changes the volume the split applies to.
The decision checklist
Work through these in order; the first mismatch tells you your depth.
- Do you know your attach rate yet? If no — go shallow, measure, then revisit. Depth is an optimisation, and you cannot optimise an unmeasured number.
- Is insurance core to your roadmap or an ancillary line? Ancillary lines rarely justify API-level ownership.
- Can your team commit to maintaining a regulated UI through product and wording changes — not just building it once? If not, widget is your ceiling, and that is fine.
- Does your checkout already collect the data that would make a native flow shorter? If you hold verified identity and asset data, API depth converts that into fewer questions. If you do not, a native build reproduces the vendor's flow at higher cost.
- Is there a regulatory reason the sale cannot complete in your interface? Some products and markets constrain where binding can happen — ask before you architect.
Changing depth later
The depths are not a one-way door, and the common path is inward: launch white-label or widget, prove the economics, then take the highest-traffic product native while leaving long-tail products on the widget. A well-designed platform keeps the underlying objects — quotes, policies, documents — identical across depths, so migrating is a frontend project, not a re-integration. Ask any vendor you evaluate to confirm exactly that, in writing, before you choose your starting point.