Process API
A Process API is the middle tier in MuleSoft's API-led connectivity model.
Definition
A Process API is the middle tier in MuleSoft's API-led connectivity model. It orchestrates and shapes data drawn from one or more System APIs (and sometimes other Process APIs), holding the business logic that turns raw system data into something a specific business process needs.
A Process API does not talk to databases or backend systems directly. Instead it calls System APIs, then merges, transforms, and enriches their responses to model a business need. Experience APIs and other consumers call the Process API for that shared logic, so the rules live in one place rather than being copied into every channel.
Where the Process tier sits in API-led connectivity
The three layers and the job of the middle tier
API-led connectivity organizes integrations into three layers, each with one job. System APIs sit at the bottom and connect directly to core systems like a CRM, an ERP, or a database, exposing their data in a stable, reusable way while shielding the system of record from disruption. Experience APIs sit at the top and reshape data for a specific channel, such as a mobile app or a partner portal. The Process API is the layer in between. Its job is to model a business process, not a system and not a channel. A single Process API might read a customer from a Salesforce System API, pull that customer's orders from an e-commerce System API, then merge the two into one unified view. That merge, the field mapping, and any rules about what counts as an active customer all live in the Process tier. Because the logic sits here once, several Experience APIs can call the same Process API and get identical behavior. The MuleSoft Trailhead module describes Process APIs as orchestrating and processing data from multiple System APIs and other Process APIs to create reusable business logic that meets specific organizational needs.
Orchestration is the core responsibility
Orchestration means calling several APIs in a coordinated sequence and weaving their results into a single response. A Process API for order fulfillment is a good example. It might call an inventory System API to confirm stock, a payment System API to authorize a charge, and a shipping System API to create a label, then return one consolidated result to whatever asked. None of those backend systems know about each other. The Process API is the only place that understands the full sequence. This is where conditional logic lives too. If inventory is short, the Process API decides whether to split the shipment or reject the order. If payment fails, it decides whether to retry or roll back. MuleSoft's own guidance frames the process layer as the place where business logic and orchestrations are contained, reading data from the system layer and merging it into a unified business process view. Keeping this coordination out of the System APIs matters. A System API should stay a clean, reusable window onto one system, with no opinion about how any particular process strings calls together.
Reuse is the payoff for getting this layer right
The reason to invest in a Process tier is reuse. Without it, every consumer that needs a unified customer view would write its own joins against the System APIs, and those joins would drift apart over time. One team might count a closed account as active while another excludes it. By putting that logic in a Process API, every consumer inherits the same answer. This reuse compounds. A Process API can call other Process APIs, so a high-level process such as customer onboarding can build on smaller processes like address validation or credit checks. Each piece is published as a discoverable asset that other teams can find and consume on their own. Trailhead describes this layered approach as making APIs modular, reusable, and easy to scale as business demands evolve, which reduces dependency on central IT. The practical effect is that new projects assemble existing Process APIs instead of rebuilding integration logic, which is the whole point of building an application network rather than a pile of point-to-point connections.
Decoupling and who owns each layer
The three layers are deliberately decoupled. A consumer calls a Process API and never touches the system underneath, so the team running the backend can re-platform, change schemas, or swap vendors as long as the System API contract holds. The Process API absorbs that change in one spot rather than every consumer breaking at once. Ownership tends to follow the layers in mature setups. System APIs are often owned by central IT or the team closest to each backend, because they require deep knowledge of the source system. Process APIs are owned by teams that understand the business process being modeled, since the value here is correct business rules, not connection plumbing. Experience APIs are frequently owned by the app or channel teams who know exactly what their interface needs. This split lets central IT keep governance and visibility over the foundational layers while line-of-business teams move faster on top. Anypoint governance rulesets can apply centralized standards across all of these, from design-time specifications to deployed instances, so decoupling does not mean losing control.
Design habits that keep a Process API healthy
A well-built Process API stays focused on one business process and resists becoming a dumping ground. The most common anti-pattern is a Process API that reaches straight into a database or hard-codes connection details, which quietly turns it into a System API and destroys the reuse story. Keep backend access behind System APIs so the process layer only ever calls other APIs. Statelessness is the next habit. A Process API should take a request, orchestrate the calls, and return a result without holding session state between requests, which keeps it horizontally scalable. Data transformation belongs here and is usually written in DataWeave, MuleSoft's transformation language, to map and merge the System API responses into the shape the process needs. Error handling deserves real thought, because a Process API can fail partway through a multi-system orchestration. Decide up front how to handle a partial success, such as inventory reserved but payment declined, and whether the process compensates, retries, or surfaces a clear error. Versioning the Process API contract also protects the many consumers that may come to depend on it.
Process APIs in the Salesforce and Agentforce picture
MuleSoft is part of the Salesforce platform, and the Process tier is how Salesforce data joins the rest of an enterprise's systems. A Process API can blend Salesforce records with data from an ERP, a billing platform, and a logistics provider, then expose one clean interface that an Experience API or another application consumes. This is the connective tissue that lets Salesforce act on data it does not natively store. That role grows with agentic use cases. Salesforce architecture guidance positions MuleSoft as the layer that gives agents governed, reusable access to enterprise systems, and Process APIs are where the reusable business actions are assembled. An agent that needs to check an order status, update a customer record, and trigger a shipment can call a single Process API that orchestrates those steps, rather than wiring the agent to every backend directly. The same reuse and decoupling that benefit human-built channels apply to AI consumers. A Process API published once as a trustworthy, well-governed asset can serve a web app, a mobile app, and an Agentforce agent from the same definition.
How to design a Process API
Designing a Process API means specifying its contract, deciding which System APIs it will orchestrate, and building the transformation and error logic that models the business process. Here is the shape of that work in Anypoint Platform.
- Define the business process and its contract
Pin down the single business process this Process API serves, such as order fulfillment or unified customer view. Write the API specification (typically in RAML or OpenAPI) describing the resources, request, and response the consumers will see, independent of any backend.
- Identify the System APIs to orchestrate
List the System APIs that hold the data you need and confirm each one exposes the operations required. The Process API will call these rather than any database directly, so missing a needed System API is a signal to build or extend one first.
- Build the orchestration and transformation flow
Implement the flow that calls the System APIs in the right order, then merge and transform their responses with DataWeave into the shape your contract promises. Add the conditional logic the process needs, such as splitting a shipment when stock is short.
- Add error handling, then publish and govern
Decide how partial failures behave (retry, compensate, or return a clear error), and implement it. Publish the API as a reusable asset in Anypoint Exchange, apply governance rulesets and policies, and version the contract so consumers can depend on it safely.
The one business process this API models; keep it focused rather than letting it sprawl across unrelated concerns.
The set of System APIs (and possibly other Process APIs) this layer calls; it should never reach a backend system directly.
The DataWeave mappings that merge and reshape System API responses into the contract's response format.
The agreed behavior when one orchestrated call fails midway, covering retries, compensation, and the error returned to consumers.
- If a Process API connects straight to a database or hard-codes system credentials, it has become a System API and loses its reuse value. Always go through a System API.
- Stuffing unrelated business logic into one Process API creates a monolith that is hard to reuse. Split distinct processes into separate Process APIs.
- Skipping a partial-failure plan is risky in multi-system orchestration, where payment may succeed after inventory was reserved but shipping failed.
- Changing the Process API contract without versioning can break every Experience API and agent that depends on it.
Prefer this walkthrough as its own page? How to Process API in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Process API.
Hands-on resources to go deeper on Process API.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In MuleSoft's API-led connectivity, what role does a Process API play?
Q2. Why does API-led connectivity place shared business logic in a Process API?
Q3. Which task is a Process API specifically responsible for in the three-tier model?
Discussion
Loading discussion…