Ask a claims or underwriting leader what they want from modernization and you rarely hear “a new core system.” You hear things like: I want adjusters to see coverage without opening three screens. I want broker submissions to arrive in the underwriting queue already structured. I want a partner’s FNOL app to create a claim without someone rekeying it.
Those are capability requests, not platform requests. An API-first approach takes them literally. Instead of replacing the policy and claims systems to deliver them, you expose the specific capabilities claims and underwriting teams need through well-designed interfaces, and let new workflows, AI services, and partners build on those interfaces while the core stays where it is.
This post lays out a practical path: what to expose first, how to move safely from reading data to changing it, and what to avoid so your APIs don’t become the next generation of legacy.
Start from decisions, not from the database
The most common mistake in API programs is starting with the system: listing its tables and exposing them one by one. The result is an interface that mirrors the core’s internal structure, leaks its quirks to every consumer, and changes whenever the core changes.
Start instead from the decisions people make every day:
- Claims: Is this loss covered? What is the deductible and the limit? Who else is involved? What has already been paid? What documents are outstanding?
- Underwriting: Is this risk in appetite? Have we seen this insured before? What is the loss history? What did we quote last year, and what changed? Which authority level does this need?
Each decision implies a small set of capabilities, such as get coverage summary for a policy at a date of loss, or get prior submissions and quotes for an insured. Those become your first API products. They are stable because the business question is stable, even when the systems behind them change.
The four-rung ladder
A safe API-first path climbs in rungs. Each rung adds capability and risk, so each needs its own controls.
Rung 1: Read-only visibility
Expose the information people and services need to see: policy and coverage summaries, claim status and financials, party and broker details, document lists. Read-only APIs carry the least risk and deliver immediate value. An adjuster’s workbench, a broker portal, or an AI assistant can all show the same trusted answer without screen-scraping.
Controls to have in place: authentication per consumer, field-level permissions (not every consumer needs bank details or medical information), and logging of who accessed what.
Rung 2: Assisted intake
Next, accept structured inputs that create work, not records: a new submission placed in an underwriting queue, a first notice of loss lodged for handler review, a document attached to a claim file. Nothing touches the policy or claim of record until a person or a defined rule accepts it.
This is where AI document extraction usually plugs in. Submissions, loss runs, invoices, and surveys are turned into structured data with links back to the source pages, then passed through the intake API for review.
Rung 3: Recommendations
Now expose services that return a suggestion alongside the evidence for it: a triage score for a new claim, an appetite assessment for a submission, a reserve range for a desk-adjusted claim, a list of missing documents. The core still holds the decision. The API returns a recommendation, the reasons, and the data it relied on, so the person accepting it can see why.
Rung 4: Governed write-back
Finally, allow approved changes to flow back into the core: an endorsement issued, a reserve updated, a payment authorized, a claim closed. This rung needs the strongest controls:
- Every write is tied to an identity and an authority level.
- Rules decide which changes can be applied automatically and which need human approval.
- Writes are idempotent, so a retry never creates a duplicate payment or endorsement.
- Every change is recorded with its inputs, the recommendation (if any), the approver, and the result.
Many organizations find that most of the operational benefit arrives at rungs one through three. Rung four is worth reaching, but it doesn’t have to come first.
What to expose first
A useful first wave for most carriers and MGAs looks like this:
- Coverage summary at date of loss, for claims handling, FNOL, and broker service.
- Claim status and next action, for broker portals, claimant updates, and “where is my claim?” deflection.
- Submission intake, accepting structured submissions plus attached documents into the underwriting queue.
- Insured history, covering prior submissions, quotes, policies, and claims for an insured, for underwriting and fraud review.
- Document attach and retrieve for claims and policy files.
Each of these serves several consumers at once, which is what makes an API worth building.
Treat each API as a product
APIs that last have owners. For each one, name a business owner (who decides what it should do) and a technical owner (who keeps it running). Write a contract before writing code, covering fields, meanings, error behaviour, and service levels, and test every release against that contract. Version deliberately, and give consumers notice before retiring anything.
Insurtech partners and brokers are often the first external consumers. Clear documentation, a sandbox with realistic test data, and predictable versioning do more for partner adoption than any number of features.
Anti-patterns to avoid
- Table-shaped APIs that expose the core’s internal structure and break with every core change.
- Screen-scraping behind an API facade. Fine as a short-term bridge, but call it what it is and plan its replacement.
- One giant integration hub that every change must pass through, recreating the bottleneck you were trying to remove.
- Write access first. Skipping straight to rung four because a vendor demo needed it.
- No consumer inventory. If you don’t know who calls an API, you can never safely change it.
Where AI attaches, and why APIs make it governable
AI services for claims and underwriting (document extraction, triage, summarization, appetite checks) need two things from the core: trusted data in, and a controlled path for results out. A clean API layer provides both. It also gives governance teams a single place to enforce permissions, log every AI-assisted recommendation, and see which decisions were automated and which were reviewed.
Illustrative example: an MGA writing cyber and marine programs might expose an insured-history API and a submission-intake API in its first quarter. AI extraction structures incoming broker submissions and posts them to the intake API. Underwriters see the extracted data, the source documents, and the insured’s prior history in one view. The policy administration system itself hasn’t changed.
Measuring progress
Useful signals include the number of workflows using APIs instead of swivel-chair rekeying, the share of submissions and FNOLs arriving through structured intake, time for a new partner to integrate, API availability and error rates, and the number of screen-scraping bridges retired.
Modernization you can feel this quarter
An API-first path doesn’t replace the eventual conversation about the core. It changes the terms of that conversation. By the time you decide what to do with the legacy platform, the workflows your people and partners rely on already run on interfaces you control, and the core has become one implementation behind them rather than the center of everything.
Find the first capabilities worth exposing. Take the Aketud Insurance AI Readiness Assessment to map claims and underwriting decisions to the capabilities behind them, and plan an API-first path that doesn’t require rip-and-replace.
