The first integration I ever built that I was truly proud of was also the one that hurt us the most two years later.
It worked. It was fast. It connected our order system directly to the CRM, with all the transformation logic packed neatly inside one service.
Then marketing wanted the same order data in their portal. Then finance wanted it in their reporting tool. Then a partner wanted it through an API.
Each request was "just one more integration". Within eighteen months we had seven copies of the same logic, each slightly different, each owned by a different team, and nobody could tell you which one was correct.
That is the problem API-led connectivity was designed to solve.
What API-Led Connectivity Actually Is
API-led connectivity is a way of organizing integrations into reusable layers of APIs, instead of building a new point-to-point connection every time someone needs data.
The idea was popularized by MuleSoft, but the thinking behind it is platform-neutral. You can apply it with any integration technology.
The core idea is simple:
Build each capability once, expose it as an API, and let everyone reuse it.
To make that work, APIs are split into three layers, each with a different job.
Layer 1: System APIs
System APIs sit directly on top of your systems of record: ERP, CRM, billing, HR, the mainframe nobody wants to touch.
Their job is to unlock data and hide complexity.
A good System API means nobody else in the organization needs to know that customer data lives in three tables with cryptic column names, or that the billing system only accepts SOAP requests on Tuesdays (I wish I was joking).
System APIs should:
- Expose clean, stable resources like Customer, Order or Invoice
- Hide the underlying system's quirks, protocols and data models
- Change slowly, because many things will depend on them
When you replace the backend system later, you rewrite the System API. Everything above it stays the same. That alone has saved programs I have worked on months of effort.
Layer 2: Process APIs
Process APIs are where the business logic lives.
They combine and orchestrate System APIs to deliver something meaningful to the business. For example, a "Customer 360" Process API might pull customer details from CRM, orders from ERP and open invoices from billing, then merge them into one consistent view.
Process APIs should know nothing about who is calling them, and nothing about where the data physically comes from. They only know the business process.
This is the layer most teams underinvest in. And it is the layer that gives you real reuse.
Layer 3: Experience APIs
Experience APIs are shaped for a specific consumer: a mobile app, a web portal, a partner, and increasingly, an AI agent.
A mobile app might need a small payload with only five fields. A partner might need a different format and stricter security. Instead of bending the Process API for every consumer, you create a thin Experience API on top.
Experience APIs change often. That is fine. They are cheap to build because the heavy lifting already happened below them.
Why the Layers Matter
When I explain this to teams for the first time, the most common reaction is:
"Isn't this just more APIs to build and maintain?"
It is a fair question. In the short term, yes. Your first project will feel slower.
But look at what happens on the second, third and tenth project:
- Reuse: the second team that needs customer data does not build anything new in the lower layers.
- Speed: new channels only need an Experience API, often in days rather than months.
- Change isolation: replacing a backend touches one System API, not twenty integrations.
- Governance: you can secure, monitor and version capabilities in one place.
- Ownership: each layer has a clear owner and a clear purpose.
The value of API-led connectivity is not in the first project. It is in the compounding effect across the portfolio.
Where Teams Go Wrong
I have seen API-led programs succeed brilliantly, and I have seen them turn into expensive bureaucracy. The difference usually comes down to a few mistakes.
Treating the layers as a religion
Not every integration needs three layers. A simple, internal, one-off data sync does not need an Experience API and a Process API wrapped around it. The layers are a guide for reusable capabilities, not a rule for every flow.
Building System APIs that mirror the database
If your System API is just a REST wrapper around table names, you have not hidden any complexity. You have just moved it. Design System APIs around business resources, not around how the backend stores data.
Putting business logic in the wrong layer
Business rules creeping into Experience APIs is the most common anti-pattern I see. It feels faster at the time. Six months later, the mobile app and the web portal calculate discounts differently, and nobody knows why.
Forgetting that reuse needs discoverability
An API nobody can find will never be reused. You need a catalog (MuleSoft calls it Exchange), good documentation, and teams who actually look there before building something new.
API-Led Connectivity in the Age of AI
There is a new consumer arriving at the top of the diagram: AI agents.
Agents need well-described, well-governed capabilities they can discover and call. That is exactly what a mature API-led architecture provides. Organizations that invested in clean System and Process APIs are finding it much easier to make their enterprise "agent-ready" than those sitting on a pile of point-to-point integrations.
In many ways, API-led connectivity was preparing us for agents before we knew they were coming.
How to Get Started
If you are introducing API-led connectivity, my advice is to start small and prove the value:
- Pick one high-demand business domain, like Customer or Order.
- Build a solid System API for its core system of record.
- Build one Process API that delivers real business value.
- Put two different consumers on top of it and measure the reuse.
- Publish everything in a catalog and tell people it exists.
Then repeat, domain by domain.
Final Thought
API-led connectivity is not really about APIs.
It is about changing how an organization thinks about integration: from projects that connect systems, to products that expose capabilities.
Once that mindset shift happens, the layers almost take care of themselves.