API-Led Connectivity
API-Led Connectivity is an architectural approach promoted by MuleSoft (a Salesforce company) that organizes integrations into three layers of APIs: System APIs (connecting to backend systems), Process APIs (orchestrating business logic), and Experience APIs (serving data to end-user applications).
Definition
API-Led Connectivity is an architectural approach promoted by MuleSoft (a Salesforce company) that organizes integrations into three layers of APIs: System APIs (connecting to backend systems), Process APIs (orchestrating business logic), and Experience APIs (serving data to end-user applications). This layered approach promotes reusability, agility, and governance across an organization's integration landscape.
In plain English
“API-Led Connectivity is a way of organizing your integrations so they are easier to reuse. Instead of building one giant messy connection between two systems, you split the work into three tidy layers: one that talks to the raw system, one that handles business rules, and one that feeds the app people actually use.”
Worked example
Bartholomew Capital's integration team rebuilds the customer-onboarding flow using API-Led Connectivity. They split the work into three layers: a System API exposes the legacy mainframe (read account, write account, get balance), a Process API orchestrates onboarding business logic (KYC checks, ACH verification, welcome email), and an Experience API serves the mobile-banking app with exactly the data it needs in mobile-friendly JSON. When the business adds a web banking app next quarter, it gets its own Experience API on top of the same Process API - no rework of the mainframe System API. The 3-layer split is what makes the integration reusable.
Why API-Led Connectivity matters
MuleSoft promotes API-Led Connectivity as a structured alternative to point-to-point integrations. The three layers (System APIs, Process APIs, and Experience APIs) each have a clear responsibility: System APIs abstract the underlying backend (Salesforce, SAP, a database), Process APIs compose multiple System APIs to implement business logic, and Experience APIs shape the data for a specific consumer like a mobile app or partner portal.
The payoff of adopting this approach is compounding reuse. Once you build a System API for 'Customer' against SAP, every future Process API that needs customer data calls the same endpoint rather than re-integrating with SAP. This reduces duplication, simplifies governance, and lets integration teams move faster on new projects because the hardest parts of a connection already exist as reusable building blocks.
How organizations use API-Led Connectivity
Built a System API over their legacy billing database, then composed it with a Salesforce System API through a Process API that handles order-to-cash logic. A mobile team later consumed that Process API through a lightweight Experience API without needing to understand either backend.
Adopted API-Led Connectivity as part of a multi-year integration modernization program. Within 18 months, their catalog of reusable System APIs meant that new integration projects took days instead of weeks because the hardest parts already existed.
Uses API-Led Connectivity to isolate backend changes from frontend applications. When they migrated from an on-premise ERP to a cloud one, only the underlying System API needed to change; the Process and Experience APIs above it stayed stable.
Trust & references
Straight from the source - Salesforce's reference material on API-Led Connectivity.
- Tutorial: Build an API from Start to FinishMuleSoft Documentation
Test your knowledge
Q1. What are the three layers of API-Led Connectivity?
Q2. Which layer is responsible for orchestrating business logic?
Q3. What is the main benefit of API-Led Connectivity over point-to-point integration?
Discussion
Loading discussion…