The Number of APIs of a Core System Is Like the Megapixels of a Camera

Third part of a series of articles that tries to cut through the fluff in insurance core system marketing and to align terms for core system buyers.

In this 4-part series

1. Cloud-Native — Read here

2. Configurability — Read here

3. API Counts — Current article

4. Microservices — Coming soon

"We have 2,500+ APIs." "Over 10,000 APIs." Few numbers appear more often in core system marketing and carry a larger gap between what they claim and what they mean. API counts are the megapixels of insurance software: easy to print, easy to inflate, but they can't be the sole measure of the picture.

Not all APIs are for you

The first thing the headline number hides is audience. A modern core system exposes interfaces to very different consumers: internal microservices talking to each other; the back-office portal; customer-facing apps; the integration surface for your IT team and system integrators; and so on. These layers differ in purpose, in granularity, in stability, and above all in magnitude.

The market reflects this confusion in a proliferation of prefixes: Open APIs, Core APIs, Atomic APIs, Kernel APIs, Partner APIs, System APIs, Experience APIs. Vendors rarely define which layer a number refers to. When the layers are blended, the count is not information but theatre.

When a big number is a red flag

A five-digit API count is not a sign of richness but a symptom of API sprawl (this article from IBM is a good reference). In our experience it traces back to three architectural causes:

1. Exposed internals. The vendor counts every interface between its own microservices. You are looking at the system's plumbing, not its product.

2. Shattered operations. A single business action ("create a quotation") is split across many fine-grained calls instead of one business-semantic API. The integrator then inherits the orchestration burden, complex exception handling, and fragile transactional state management.

3. Redundant design. Each business domain grew its own services instead of sharing well-layered platform capabilities. The API count goes up, while the coherence goes down.

All three yield the same architectural trap: fragile integrations, heavy maintenance burden, and implementation estimates that may quietly double.

What to probe as a buyer

A reasonable API count is a good start, but nothing more. The questions that predict your integration experience include:

• How many API calls does it take to create a quote, issue a policy, register a claim, end to end? The well-designed, business-semantic APIs handle this in a clean, straightforward sequence, not dozens of fine-grained endpoints.

• What is the developer experience? Does the platform offer modern, interactive developer portals, well-organised OpenAPI specifications, and sandboxes—or an outdated static PDF that becomes a maintenance nightmare?

• What is the API changelog and the deprecation policy? Governance and backward compatibility are what matter in the years to come (and core systems are notoriously long-lived).

• Can my team compose new APIs? On top of well-governed core APIs, is there a governed platform on which your IT team and partners can assemble, expose, and manage new interfaces in a standardised, maintainable way?

  
  

Why this matters in the agentic AI era

AI agents are the newest and most demanding API consumers (whether directly or via MCP or CLI). An agent interacting with well-organised, business-semantic capabilities works reliably. An agent confronted with thousands of fine-grained, overlapping endpoints burns its context on navigation and is at risk to pick wrong. 

API sprawl that may merely annoy a human integrator may actively break agentic operations. MCP and agent interfaces are only ever a surface expression of what lies beneath. A clean, governed, business-semantic API architecture is what makes a core operable by AI agents. In the AI era, API quality compounds, while pure API quantity adds noise.

Next time someone boasts a large API count, don't be impressed. Be curious. Ask what's being counted, and how their APIs are organised and governed - the answer will tell you more than any number.