Core MuleSoft concept · 8 min read

API-led connectivity explained: System, Process, and Experience APIs

By the MulePrep team · Updated June 2026

API-led connectivity is MuleSoft's approach to connecting systems with reusable APIs organized in three layers: System, Process, and Experience. System APIs unlock data from systems of record, Process APIs orchestrate that data across systems, and Experience APIs reshape it for a specific consumer. This guide walks each layer, follows one request end to end, and covers the layer distinctions the certification exams test most.

What API-led connectivity is

API-led connectivity is an approach to integration that connects systems through reusable, purpose-built APIs rather than one-off, point-to-point connections. Instead of wiring each application directly to every other application, you expose each capability as an API and let other things consume it. As the number of systems grows, point-to-point integration grows roughly with the square of the connections, while a layered API approach keeps each system unlocked once and reused many times.

The model organizes those APIs into three layers, each with a distinct responsibility:

• System APIs unlock data from a system of record and hide its details.
• Process APIs orchestrate and combine data across systems to deliver a business capability, independent of the source systems and the consuming channel.
• Experience APIs reshape a capability for one specific consumer, such as a mobile app, a web front end, or a partner.

The layers are a separation of concerns, not a rule about how many APIs you must build. A small integration might not need all three. The value shows up at scale: when responsibilities are cleanly split, a change in one place rarely forces a change everywhere else, and different teams can own different layers without colliding.

System APIs

A System API exposes one underlying system - Salesforce, SAP, a database, a mainframe, a SaaS product - behind a stable, well-defined interface. Its job is to unlock the data and functions of that system and to insulate everything above it from how the system actually works.

What belongs in a System API

• The connection details and authentication for one system.
• A clean representation of that system's objects (for example, a Salesforce account or an SAP customer record).
• Translation from the system's native quirks - field names, formats, pagination - into a consistent API contract.

What does not belong in a System API

Cross-system orchestration and consumer-specific shaping do not belong here. A System API should not call another System API to merge data, and it should not know or care whether a mobile app or a web page is the eventual consumer. Keep it focused on one system so it can be reused by many processes. When the underlying system changes - a Salesforce field is renamed, SAP is upgraded - you fix it once, inside that System API, and nothing above it needs to change.

Process APIs

A Process API implements a business capability by orchestrating and combining data across systems. It is where logic that spans more than one system lives: calling several System APIs, merging their results, applying business rules, sequencing steps, and handling the flow of a process. The defining trait is that a Process API is independent of both the source systems and the consuming channel.

Independent of source

A Process API talks to System APIs, not directly to the underlying systems. So a "Customer" process that combines a CRM record with an ERP record does not embed Salesforce or SAP connection logic. If you later replace SAP with a different ERP, you change that ERP's System API; the Process API keeps calling the same contract.

Independent of channel

A Process API also does not shape its output for any one consumer. It returns a complete, channel-neutral view of the capability. A mobile app, a web app, and a partner integration can all build on the same Process API because none of them is baked into it.

Experience APIs

An Experience API reshapes a capability for one specific consumer. It takes the channel-neutral output of a Process API (or, for a simple read, a System API) and adapts it to exactly what that consumer needs: the right fields, the right format, the right amount of data for that screen or that partner.

Why this is a separate layer: a phone, a desktop browser, and a B2B partner want very different things from the same underlying data. A mobile app wants a small payload tuned for a slow connection and a small screen. A partner may want a stricter contract and only a subset of fields. Putting that shaping in the Experience layer keeps the Process API clean and lets you add a new consumer by adding a new Experience API, without touching the orchestration beneath it.

• Trim or rename fields for a specific consumer.
• Aggregate or paginate to suit a device or screen.
• Apply consumer-specific formatting, such as a JSON shape the app expects.

What does not belong here: cross-system orchestration and business rules. If you find an Experience API calling three System APIs and merging them, that orchestration belongs in a Process API instead.

A worked example, end to end

Suppose a retailer wants a mobile app to show a unified customer profile. Customer identity and contact details live in Salesforce; order history and billing live in SAP. Here is how the request flows through the three layers.

1. System APIs unlock each system

• A Salesforce System API exposes the customer's profile - name, email, account ID - behind a clean contract, hiding Salesforce's object model and authentication.
• An SAP System API exposes order history and billing for a given customer ID, hiding SAP's native formats.

Each is reusable on its own. Any other project that needs Salesforce contacts or SAP orders can call these same APIs.

2. A Process API orchestrates and combines

A Customer process API receives a customer ID, calls the Salesforce System API for the profile and the SAP System API for orders and billing, then merges both into a single, complete customer view. It applies any business rules - for example, flagging a customer as "high value" based on order totals. It returns this view in a channel-neutral form. It knows nothing about phones.

3. An Experience API reshapes for the mobile app

A mobile Experience API calls the Customer process API, then trims the full view to just what the app screen needs - name, last three orders, account status - and shapes the JSON the app expects. If the web team later wants a richer view, they add a separate web Experience API on top of the same Process API. Nothing below changes.

The reuse is the point. Add a partner portal next year and you write one more Experience API. Swap SAP for another ERP and you change one System API. The orchestration in the middle stays put.

Why it matters and the exam distinctions people miss

Beyond the exam, the three-layer split is what makes a large integration estate maintainable: each system is unlocked once, business logic sits in a known place, and new channels are cheap to add. The certification exams test whether you have internalized that discipline. A few distinctions trip people up repeatedly.

Orchestration is a Process responsibility, not an Experience one

Combining data from multiple systems is the signature of the Process layer. A common wrong answer puts merge-and-aggregate logic in an Experience API because that is where the consumer sits. If an API calls more than one System API and stitches the results together, it is acting as a Process API.

System APIs stay consumer-agnostic

A System API should never shape its output for a particular app or trim fields "because the mobile team asked." That coupling defeats reuse. Consumer-specific shaping is the Experience layer's job.

Channel-neutral means no device assumptions in the Process layer

"Independent of channel" is exam language for: the Process API returns a complete view and makes no assumptions about who consumes it. If a description mentions formatting for a phone or paginating for a screen, that is the Experience layer talking.

Reuse flows upward, and not every project uses all three

Many Process APIs can reuse one System API; many Experience APIs can reuse one Process API. The layers are responsibilities, so a simple read-only feature might expose a System API directly to an Experience API with no Process API in between. The model does not mandate three hops for every call.

API-led connectivity appears across all four MuleSoft tracks but carries the most weight on the architecture exams, where layer-responsibility questions are common. Each exam is 60 multiple-choice questions in 120 minutes, closed book, with a 70% passing score, and the credential is valid for two years. For current exam fees and policy, always check the official Trailhead credential page rather than a number you read in a blog - for example, the Platform Architect I and Integration Architect I pages.