The API Is the Product Now: Why Distribution Buys Integration Speed

A digital broker platform decides it has room for two new carriers this quarter. Appetite and price get checked first, and half the candidates clear that bar comfortably.

Then someone asks how long the integration takes, and the shortlist collapses.

That question used to be an implementation detail, settled after the commercial conversation by people who were not in the room. It is now the commercial conversation, and the spread between the best and worst answers has become absurd.

Coterie, a small commercial MGA, says it completes a full distribution partner integration in three weeks. In August 2026 its chief revenue officer, Mark Seich, told Insurance Business that colleagues arriving from Fortune 100 carriers describe the same problem back home differently: their organisations “tried to solve that for two years and they’re still so far behind”.

Three weeks against two years is not a rounding error. It is the difference between winning a distribution partner and never being shortlisted for one.

Money is not the constraint in that comparison, and neither is engineering headcount; the Fortune 100 carriers have far more of both. Seich points at flexibility instead. Large carriers tend to offer one standardised integration and expect every partner to conform to it, which is why his test for a carrier is blunt.

“Is it an off-the-shelf solution? How fast can they accept what you need?”
Mark Seich, chief revenue officer, Coterie

What the partner is really buying

For most of the industry’s history a distribution partner chose a carrier on appetite, price, capacity and service.

The integration was a detail that got sorted out afterwards.

That order has reversed. When a broker platform, an embedded partner or a comparison site decides who to work with, the integration is part of the product on offer, and often the deciding part. A carrier with slightly worse pricing and a two-week integration beats a carrier with better pricing and a nine-month one, because the second carrier is quietly asking the partner to spend an entire engineering roadmap on it.

Coterie’s own numbers suggest partners are making that trade. Over 650 channel partners, with the majority of business arriving through API connections rather than a portal. More than $200m of direct written premium in 2025, a 66% year-over-year rise in in-force premium, and over 100,000 policies in force. None of that came from a pricing advantage.

Scale the same logic up and the number gets uncomfortable. Gallagher Re puts total MGA premium above $125bn, roughly 12.5% of US property and casualty premium, growing about 10% in 2025 with a similar forecast for 2026. A meaningful share of that is premium which used to sit on carrier paper and moved because somebody else was easier to plug into. For an MGA or coverholder, the integration timeline is the commercial argument, which makes it a number worth measuring rather than estimating.

Two years is arithmetic, not incompetence

Look at what the two-year carrier is working with. PwC research puts insurers’ spend on merely maintaining existing systems at around 70% of the annual IT budget, and what remains has to cover regulatory work, security and every other initiative before anyone reaches partner integration.

While that budget shrinks, the penalty for awkward servicing has moved from new business to renewals: J.D. Power found only 55% of small commercial customers said they “definitely will” renew in 2025, down six points. A partner integration is therefore competing for the smallest slice of the budget against the fastest-growing risk to the book, which is a fight it loses in most planning cycles.

Then there is the gap in the machinery itself. McKinsey estimates 95% of personal lines policies already move through straight-through processing, while small commercial is not expected to reach that point until around 2030.

That five-year window is the ground tech-enabled MGAs are taking, and they are taking it now.

Hiding inside Seich’s remark about off-the-shelf solutions is an architecture decision made years earlier. A carrier whose products live as code inside a core system can only expose what that system was built to expose, so every partner-specific requirement becomes a change request against a release calendar. Where products, rules and rating are configuration, the integration can be shaped to the partner rather than the other way round.

That is most of the distance between three weeks and two years, and it is why Openkoda keeps product definition in a Product Builder and a rating engine a business user can change, on published flat pricing, so “can you support this” is usually answered with a configuration change instead of a quote.

The bar a partner’s engineers apply

Nobody has surveyed distribution partners on what they require, and the list below is not research. It is prescriptive, drawn from ordinary API developer-experience practice, and it is roughly what a partner’s engineers will judge you against on the first technical call.

• The full policy lifecycle, not only quoting. Quote, bind, issue, endorse, renew, cancel and claims. A quote-only API leaves the partner rekeying everything the moment a sale actually happens, which is the exact work the integration was meant to remove.
• Self-serve sandbox credentials, so a developer can start building without booking a sales call, with a certification checklist gating access to production.
• OAuth 2.0 with scoped tokens rather than long-lived shared keys, so permissions can be narrowed per partner and revoked without breaking everyone else.
• Documentation somebody outside your building can follow. Cheapest item here, most often skipped, and the reason plenty of integrations run to six months instead of three weeks.
• Webhooks instead of polling. Partners need to know when a referral clears underwriting or a policy is issued, without hammering an endpoint on a timer.

None of it is exotic. The standard is being set outside insurance, by every other API a partner’s developers touched that week.

The lifecycle item is where carriers most often fail, because quoting was built first and everything after it lives in a different system. Endorsements, renewals, cancellations and claims have to come out of policy administration the same way quotes do, and the same product has to reach a branded form, an API and an embedded partner checkout without being rebuilt three times over. Anyone currently stuck on a partner spec has a good test case to bring to a demo.

Chubb Studio removes the size excuse

Chubb Studio launched in 2020 as a distribution platform for embedded partners. It now serves more than 150 partners across e-commerce, banking, retail and mobility through APIs and SDKs, has gone multi-carrier so partners can embed third-party products alongside Chubb’s, and picked up an AI optimisation engine in November 2025.

Chubb is not a small company. It treated distribution technology as a product with its own roadmap and its own partners, rather than as an integration backlog owned by whoever had capacity that quarter.

The data layer quietly stopped being an argument

ACORD, whose AL3 flat files and EDI messages defined insurance data exchange for decades, now publishes XML and JSON standards with granular, transaction-centric definitions aimed at APIs and microservices, plus conversion tooling that maps between AL3, XML, JSON and EDIFACT.

So “we have to support the legacy format” no longer counts as a reason not to build a modern API. Both can be true at once, and the mapping is a solved problem. For a carrier holding a legacy core, that usually points away from a replacement programme and towards a modern layer in front of what already exists, with products moved onto it one at a time.

Your next integrator is a model

Everything above assumes a human developer at a partner company, reading your documentation.

That assumption is expiring.

Verisk shipped it in May

On 5 May 2026, Verisk put two Model Context Protocol connectors inside Anthropic’s Claude, covering Underwriting Intelligence (ISO Indications) and XactRestore. Underwriters and claims staff can ask about loss trends, filing signals and restoration estimates in plain language, without opening a portal at all. The integration target was not a partner’s engineering team. It was a model.

The payment rails are moving the same way. Google published the Universal Commerce Protocol in January 2026 to let agents work against product catalogues directly. In March 2026 Visa joined the Machine Payments Protocol from Stripe and Tempo, and Mastercard confirmed Europe’s first end-to-end payment executed by an AI agent.

Predictions about when agents will be buying insurance at volume deserve caution. The direction is far better evidenced than any particular date.

The bar an agent sets

The requirement, though, is already legible, and it is strictly harder than the human version: API-first architecture, structured machine-readable data, documentation a model can parse, and credentials that identify and constrain an agent rather than a person.

That last item carries most of the anxiety, and it is a permissions problem rather than a new discipline. Openkoda’s MCP server lets an assistant work against a live book through the same permissions model the people in the business use, with actions confirm-gated and every call written to the audit trail. Agent readiness and governance turn out to be one feature, which is the only way either of them safely works.

A carrier that has not solved the human integration problem has no route to this one. Same plumbing, higher standard.

It cuts the other way too. Once agents are transacting against your systems, who is liable when one gets it wrong stops being hypothetical, which is what the AI agent insurance products now reaching the market exist to answer.

The industry spent two decades treating integration as something to arrange once the deal was agreed. Distribution reversed that order, and the reversal is showing up in premium: three weeks is a growth strategy, and two years is an exit from a market nobody chose to leave.

The bar is rising again before most carriers have cleared the first one. The next partner reading your documentation may not be a person, and it will not call an account manager for a workaround. It will go somewhere it can transact.