API-led connectivity

API-led connectivity organizes integration as layers of reusable, managed APIs. System APIs unlock data from core systems, process APIs combine that data into business processes, and experience APIs shape it for a specific channel such as a mobile app or a partner portal.

The approach was popularized by MuleSoft, but the idea is vendor-neutral: build integrations as products that can be reused, rather than as one-off connections.

Diagram

flowchart TB
    mobile[Mobile app] --> xm[Experience API: mobile]
    web[Web portal] --> xw[Experience API: web]
    xm & xw --> p1[Process API: order status]
    p1 --> s1[System API: ERP]
    p1 --> s2[System API: CRM]
    p1 --> s3[System API: shipping]
    s1 --> erp[(ERP)]
    s2 --> crm[(CRM)]
    s3 --> ship[Carrier service]

How it works

System APIs expose a core system’s data in a clean, stable form and hide its quirks. They rarely change.
Process APIs orchestrate several system APIs to implement a business capability, such as “get order status”.
Experience APIs tailor responses to one consumer’s needs: fields, format, security and pagination.
Managed as products. APIs are documented, versioned, secured and discoverable through an API catalog or developer portal.

Pros

Reuse: a new channel reuses existing process and system APIs instead of new integrations.
Isolation from change: replacing a backend affects only its system API.
Faster delivery once the core APIs exist.
Governance: security, rate limits and monitoring are applied consistently at the API layer.

Cons

More hops: three layers add latency and more components to run.
Up-front investment: the payoff comes only after APIs are reused.
Over-layering: simple integrations don’t need all three tiers.
Synchronous by default: request-response chains can be fragile under load.

When to use it

Organizations with many channels (web, mobile, partners) that need the same core data.
Replacing a growing web of point-to-point integrations.
When core systems will be modernized and consumers must be shielded from that change.

When to avoid it

A single application with one or two integrations.
High-volume, asynchronous data flows, where messaging or event streaming fits better.

Common pitfalls

One API per screen at every layer, which recreates point-to-point integration with more steps.
System APIs that mirror database tables, leaking the backend’s design to every consumer.
No API ownership or versioning policy, so changes break unknown consumers.

Glossary: API gateway