MuleSoft API Led Connectivity
API-led connectivity is MuleSoft's recommended approach to building enterprise integrations. Instead of creating direct, tangled connections between systems, you organize everything into three distinct layers of APIs. This approach makes integrations reusable, easier to change, and faster to build.
The Problem API-Led Connectivity Solves
Without a structured approach, large companies end up with "spaghetti integrations" — hundreds of direct connections between systems that nobody fully understands. When one system changes, many connections break. Fixing one problem creates three more. Development slows down because every new integration must start from scratch.
Spaghetti Integration vs API-Led
SPAGHETTI (point-to-point):
Salesforce <---> SAP
Salesforce <---> Oracle
Salesforce <---> Workday
SAP <---> Oracle
SAP <---> Workday
Oracle <---> Workday
(Every system talks to every other. 10 systems = 45 connections.)
API-LED (organized layers):
Salesforce SAP Oracle Workday [Backend Systems]
| | | |
v v v v
[System APIs: one per backend]
| |
v v
[Process APIs: business logic]
|
v
[Experience APIs: per consumer]
|
v
Mobile Web Partner IoT [Consumers]
Layer 1: System APIs
System APIs connect directly to a single backend system. Each backend gets its own System API. The Salesforce System API handles only Salesforce operations. The Oracle Database System API handles only Oracle queries. No System API knows or cares about other systems.
System APIs provide a clean, technology-agnostic interface to each backend. When Salesforce upgrades its API version, you update only the Salesforce System API. No other layer needs to change.
System API Examples
salesforce-system-api:
GET /contacts/{id} → query Salesforce Contact by ID
POST /contacts → create Salesforce Contact
PUT /contacts/{id} → update Salesforce Contact
oracle-system-api:
GET /customers/{id} → SELECT from Oracle Customers table
POST /customers → INSERT into Oracle Customers table
GET /orders?customerId={id} → SELECT orders for customer
sap-system-api:
GET /materials/{id} → call SAP Material BAPI
POST /purchaseOrders → create SAP Purchase Order via IDoc
Layer 2: Process APIs
Process APIs contain the business logic of your organization. They call multiple System APIs, combine the data, apply business rules, and return a unified result. A single Process API might call three System APIs to build a 360-degree view of a customer.
Process APIs do not know about the consumers (mobile apps, websites, partners). They focus purely on business processes.
Process API Example: Customer 360
customer360-process-api:
GET /customers/{id}/fullProfile
This Process API calls:
1. salesforce-system-api GET /contacts/{id} → gets contact info
2. oracle-system-api GET /customers/{id} → gets account history
3. oracle-system-api GET /orders?customerId={id} → gets orders
Then merges and returns:
{
"customerId": "CUST-001",
"name": "Alice Smith",
"email": "alice@email.com", // from Salesforce
"totalOrders": 24, // from Oracle
"lifetimeValue": 8750.00, // from Oracle
"lastOrderDate": "2024-01-10" // from Oracle
}
Layer 3: Experience APIs
Experience APIs sit at the top and serve specific consumers. The mobile app Experience API formats data for small screens with limited data transfer. The partner portal Experience API exposes only the fields a partner is allowed to see. The IoT Experience API returns minimal, lightweight payloads.
Each Experience API calls Process APIs (never System APIs directly). Experience APIs focus on the consumer's needs, not the backend details.
Different Experience APIs from Same Process API
Same Process API: customer360-process-api
Mobile Experience API (mobile-customer-exp-api):
Returns compact data (less fields, smaller payload):
{ "name": "Alice S.", "totalOrders": 24 }
Web Portal Experience API (portal-customer-exp-api):
Returns full data with rich formatting:
{ "fullName": "Alice Smith", "totalOrders": 24,
"lifetimeValue": "$8,750.00", "tier": "Gold" }
Partner API (partner-customer-exp-api):
Returns only non-sensitive data:
{ "customerId": "CUST-001", "orderCount": 24 }
Benefits of API-Led Connectivity
Reusability
When a new mobile app needs customer data, it calls the existing customer360-process-api and the existing salesforce-system-api. No new integration code is needed for the backend connectivity. The estimate for new projects drops from months to days.
Agility
When the company moves from Oracle to PostgreSQL, only the oracle-system-api changes. All Process APIs and Experience APIs continue working unchanged. The migration impacts one API instead of dozens of point-to-point connections.
Visibility
Every API in the three layers is registered in API Manager. You can see exactly who calls each API, how many requests per minute each receives, and which ones are failing. This visibility is impossible with point-to-point integrations.
Naming APIs in the Three-Layer Model
System API naming: [system-name]-sys-api Process API naming: [process-name]-prc-api Experience API naming: [consumer-name]-exp-api Examples: salesforce-sys-api sap-sys-api oracle-sys-api order-fulfillment-prc-api customer-360-prc-api onboarding-prc-api mobile-orders-exp-api web-customer-exp-api partner-inventory-exp-api
Common Mistake: Skipping Layers
Many developers get started well but then take shortcuts — an Experience API calls a System API directly, bypassing the Process layer. This feels faster in the short term but creates the same spaghetti problem inside the MuleSoft platform. Always follow the layered pattern strictly. If a Process API does not exist yet, build it first, even if it is simple.
Applying API-Led to a Real Project
A retail company wants to show unified customer information in three places: a mobile app, a customer service website, and a partner extranet. They have customer data in Salesforce, order data in SAP, and shipping data in FedEx's API.
The API-led approach:
- Build salesforce-sys-api, sap-sys-api, and fedex-sys-api (System layer)
- Build customer-360-prc-api that calls all three (Process layer)
- Build mobile-customer-exp-api, cs-portal-exp-api, and partner-exp-api (Experience layer)
Total APIs: 6. Total reusable Process and System APIs: 4. When the company adds a fourth consumer next year, they only build one new Experience API. The other 5 APIs remain unchanged.