# API-led connectivity layers and API boundaries

*MuleSoft Platform Integration Architect Study Guide · Designing architecture using integration paradigms · Last updated November 13, 2026 · https://www.certifyforce.com/study-guide/mulesoft-platform-integration-architect/designing-architecture-using-integration-paradigms/api-led-connectivity-layers-and-api-boundaries*

How to lay out System, Process and Experience APIs for a real application network: when a layer is justified, when it is not, how bounded contexts set API boundaries, and why the API model stays the maintained contract.

- Certification: Salesforce MuleSoft Platform Integration Architect
- Exam section: Designing architecture using integration paradigms
- Study guide: https://www.certifyforce.com/study-guide/mulesoft-platform-integration-architect

**Official exam objective:**

> Create high-level integration architectures using API-led Connectivity.

## What the exam expects

- Assign each capability to the System, Process or Experience layer from what it actually does, not from the diagram you started with.
- Decide when an extra layer is justified (adapting a native backend API) and when it is waste (a pass-through that changes nothing).
- Recognize that non-HTTP capabilities, such as a scheduled file transfer, can still be part of an API-led design.
- Derive API boundaries from the business domain model and its bounded contexts before settling names, paths or syntax.
- Keep the API model (RAML or OAS) maintained as the shared contract while the implementation evolves.

**API-led connectivity**: a methodical way to connect data to applications through reusable and purposeful APIs. **System API**: an API that connects directly to a core system and unlocks its data. **Process API**: an API that orchestrates System APIs and other Process APIs into reusable business logic. **Experience API**: an API that adapts Process API output for one consumer, such as a mobile app. **Bounded context**: the part of a domain model within which one API's responsibility and request-response model are defined ([API-led advantages](https://www.mulesoft.com/api/advantages-of-api-led-connectivity), [API-led essentials](https://trailhead.salesforce.com/content/learn/modules/application-networks-and-api-led-connectivity-in-mulesoft/explore-api-led-connectivity), [Common API mistakes](https://blogs.mulesoft.com/dev-guides/common-api-mistakes/)).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| Layer count | Three layers are a starting point; API-led is not strictly restricted to them. | [API-led patterns](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/) |
| Native backend APIs | A non-MuleSoft System layer can sit under a MuleSoft System API wrapper. | [API-led patterns](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/) |
| System API proxy | Lets policies such as throttling manage QoS to backend APIs. | [API-led patterns](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/) |
| Skipping Experience | A fit-for-use Process API can be consumed without an Experience layer. | [API-led patterns](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/) |
| File-based capability | A single System API can move files with no Process API. | [API-led patterns](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/) |
| Integration styles | File Transfer, Shared Database, Remote Procedure Invocation, Messaging. | [EIP using Mule](https://docs.mulesoft.com/mule-runtime/latest/understanding-enterprise-integration-patterns-using-mule) |
| API boundary basis | Domain model and bounded contexts define responsibility and request-response model. | [Common API mistakes](https://blogs.mulesoft.com/dev-guides/common-api-mistakes/) |
| Model lifecycle | Model-first, then maintained during implementation. | [Common API mistakes](https://blogs.mulesoft.com/dev-guides/common-api-mistakes/) |
| Experience API role | Adapts Process API output for a specific UI or device. | [API-led essentials](https://trailhead.salesforce.com/content/learn/modules/application-networks-and-api-led-connectivity-in-mulesoft/explore-api-led-connectivity) |

## Check yourself

- Which tools does the Common API mistakes article name for capturing a RAML or YAML model up front?
- When should an architect weigh deployment topology and expected acquisitions in a layering decision?
- Which test-time artefacts can an API model seed besides scaffolding and documentation?
- Which four integration styles does the Enterprise Integration Patterns page map to Mule objects?
- Why does API-led connectivity keep each API pertinent to its bounded context and loosely coupled?

## Sources

- [Understanding API-Led Connectivity Essentials](https://trailhead.salesforce.com/content/learn/modules/application-networks-and-api-led-connectivity-in-mulesoft/explore-api-led-connectivity)
- [5 integration patterns to debunk the myths about API-led connectivity](https://blogs.mulesoft.com/api-integration/patterns/patterns-to-debunk-api-led-connectivity-myths/)
- [Common API mistakes](https://blogs.mulesoft.com/dev-guides/common-api-mistakes/)
- [3 customer advantages of API-led connectivity](https://www.mulesoft.com/api/advantages-of-api-led-connectivity)
- [Enterprise Integration Patterns Using Mule](https://docs.mulesoft.com/mule-runtime/latest/understanding-enterprise-integration-patterns-using-mule)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 5 linked practice questions, and unlimited timed mock exams are included with the MuleSoft Platform Integration Architect pack (USD $19): https://www.certifyforce.com/practice-exams