The state of insurer APIs in India: why brokers still can't sell every product from one screen

If you have ever tried to sell more than three insurers' products from a single broker platform, you already know the truth: India's insurer API layer is not a layer. It is a patchwork of REST endpoints, SOAP hangovers, IP-whitelisted staging environments, PDF-only outputs and 'please email us the proposal' workflows dressed up as digitisation. In 2026, that patchwork is finally being wrapped and abstracted — but only by brokers and platforms willing to build the connector infrastructure themselves.

This is a working map of where insurer APIs actually are in India today: what maturity looks like insurer-by-insurer segment, where the real friction is, and how brokers are quietly shipping quote-to-issue journeys anyway.

Every insurer in India sits in one of four buckets when it comes to broker-facing API access. It has almost nothing to do with the insurer's size and everything to do with whether their digital team owns the broker channel end-to-end or has to negotiate every field with an internal underwriting owner.

• Tier 1 — Full quote-to-issue APIs. Real-time quote, prefill, e-KYC, payment, issuance and endorsement APIs. Auth is OAuth2 or signed JWT. Sandbox exists. This is 4-6 insurers across GI + Life.
• Tier 2 — Quote + proposal APIs, manual issuance. Live rating engine exposed, proposal accepted electronically, but policy issuance still needs a call-back file or an insurer-side operator to click 'issue'. 8-10 insurers.
• Tier 3 — Rate cards + upload workflows. No live quote; broker pulls a rate card or standard tariff, generates the proposal locally, then uploads to an insurer portal or SFTP for issuance. 10-12 insurers.
• Tier 4 — Email + PDF + hope. No machine interface at all. Broker emails a proposal, insurer emails back a policy PDF, everything downstream is manual reconciliation.

Three structural reasons explain the state of the market. Understanding them makes the workarounds obvious.

1. IRDAI regulates products, not interfaces

There is no equivalent of the UK's Open Banking mandate or India's own UPI-style protocol for insurance. IRDAI approves products, filings and reserves — how an insurer exposes those products to distributors is a commercial decision, not a compliance one. That means API roadmaps live in whoever's budget wants to fund them, which is usually the direct-to-consumer team, not the broker channel team.

2. Broker-channel APIs are a cost centre, not a revenue centre

For most insurers, the broker channel already places business through relationship managers. There is no top-line incentive to invest in APIs unless a large broker demands it as a condition of business. The insurers who do have Tier 1 APIs almost always got there because a top-5 broker or aggregator pushed them into it.

3. Underwriting logic still lives in people's heads

Even where the rating engine is API-exposed, edge cases — commercial risks, health with pre-existing conditions, motor with claims history — route to a human underwriter. A 'quote API' that returns a quote for 60% of cases and a 'please contact us' string for 40% is common. Brokers who don't handle this gracefully break their own funnels.

The 4-6 insurers with real end-to-end APIs share a recognisable pattern. If you're evaluating an insurer connector platform, this is the baseline they should be hitting for the top tier:

• OAuth2 client-credentials flow with a rotating client secret. IP whitelisting on top for production.
• Separate sandbox and production environments with realistic test data — not empty payloads.
• Quote API that takes structured risk parameters (IDV, NCB, add-ons for motor; sum insured, room-rent capping, riders for health) and returns premium + policy schedule JSON in under 3 seconds.
• Proposal API that accepts KYC references (PAN, Aadhaar hash, video-KYC token) plus structured proposer + insured data.
• Payment linkage — either a hosted payment page returning a token, or a direct payment gateway hand-off.
• Issuance API that accepts the proposal + payment reference and returns policy number, PDF URL and structured schedule.
• Endorsement APIs for the common change types (address, nominee, add-on toggles).
• Webhooks for asynchronous state changes — issuance confirmation, endorsement approval, claim intimation acknowledgement.

The Postman-collection view of insurer APIs is optimistic. Once you run 2,000 proposals a week through them, the reality is messier:

• Silent breaking changes. Field names shift from camelCase to snake_case between minor versions, without a changelog.
• Sandbox drift. Test environments lag production by weeks — a proposal that works in sandbox fails in prod because a required field was added.
• Rate limits nobody publishes. Insurer APIs throttle without warning, especially on the last day of the month when everyone is rushing to close business.
• Payment webhook race conditions. Issuance webhook arrives before payment webhook, or vice-versa; brokers who don't idempotently reconcile end up with duplicate policies.
• PDF-only policy schedules. Even Tier 1 sometimes returns a PDF instead of structured JSON for exotic add-ons — meaning you're right back at IDP for parts of the flow.

None of this is unique to India — it is what happens when every insurer's API team is 2-4 engineers who ship on their own cadence. The fix is a connector layer that abstracts all of it and gives the broker one clean surface.

The brokers who now sell 15-20 insurers' products from a single screen have almost all converged on the same architecture — a broker-side platform plus an insurer connector platform in between.

1. 1The broker platform (a BrokerZen-class distribution OS) owns the client, quote comparison UI, proposal capture and post-sale servicing.
2. 2The connector platform (Sparkcover, in our case) sits in the middle and normalises every insurer's API — or lack of one — into a single quote-to-issue contract.
3. 3For Tier 1 insurers, the connector is a thin adapter over the real API. For Tier 2, it wraps the quote API plus a queue for the manual issuance step. For Tier 3, it hides the SFTP upload behind the same interface. For Tier 4, it falls back to a PolicyMind-powered IDP pipeline that turns the emailed PDF back into structured data.
4. 4The broker never sees the difference. The client never sees the difference. Only the connector team knows.

Three shifts are already visible and will re-shape the landscape over the next 24 months:

• IRDAI-led standardisation on core risk-carrier data models (e.g., the Bima Sugam plumbing) will force more insurers into Tier 2+ whether they want to invest or not.
• Insurers who don't want to build broker-side APIs will increasingly rent connector-platform seats — the connector becomes their broker channel API by proxy.
• Broker platforms will stop treating 'API vs no API' as a hard boundary. The unit of integration will become the flow (quote, propose, issue, endorse, claim) — with the connector filling whichever gaps the insurer hasn't closed yet.

If you are a broker evaluating how to build or buy insurer connectivity in 2026, this is the shortlist of questions worth answering before you sign anything:

1. 1How many of your top 15 insurers by GWP have Tier 1 APIs? (Usually 3-5.)
2. 2For the rest, what does the fallback look like? Manual? IDP? SFTP? Email?
3. 3Who owns adapter maintenance when the insurer changes a field name silently?
4. 4Can you reconcile payin and commission automatically once the policy is issued? (If not, everything before this step is theatre.)
5. 5Can the platform present a single unified quote-comparison UI across all four tiers?

If the answers to those five questions are honest and the platform still holds up, you have a real path to selling every insurer's product from one screen. Anything less, and you are shipping a demo, not a distribution business.

“The winners in Indian broking over the next five years will not be the ones with the best client relationships — they'll be the ones with the best insurer connectivity layer sitting behind those relationships.”— SparkMile product team, Feb 2026