API-led integration architecture

API-led integration organises integrations into three layers. System APIs wrap each system of record behind a stable contract. Process APIs hold business logic and orchestrate across systems. Experience APIs shape data for a particular consumer, such as a mobile app, a partner portal or an AI agent. The aim is that a change in one system or channel touches one layer, not every integration.

This is a reference design. We validate the systems, APIs, limits and licences for each implementation, and GeekMidst can design and implement it through Salesforce integration services or MuleSoft integration services.

Business context

Point-to-point integrations are often how estates start: Salesforce calls the ERP, the ERP calls the marketing platform, and a script copies files overnight. Each link is simple, but the total grows quickly, credentials spread, and nobody can see where an order went missing. Middleware with layered APIs adds a platform to run, but centralises mapping, retries, security and monitoring. MuleSoft, with its Anypoint Platform for APIs and integration, is one option; other middleware and iPaaS products can implement the same pattern.

Data flow, step by step

1. A consumer calls an experience API through the gateway, which checks the token and limits.
2. The experience API calls a process API, for example "place order".
3. The process API orchestrates: it validates the request, calls the ERP and Salesforce system APIs, and publishes an event for the marketing update.
4. System APIs call the systems with idempotent requests and their own credentials.
5. Asynchronous work is queued and consumed at a rate the target can accept.
6. Changes in Salesforce flow back through Change Data Capture, read over the Pub/Sub API. High-volume events are retained for 72 hours, so subscribers must recover within that window or reconcile.
7. Failures go to the error queue and raise alerts with the correlation ID. Our order-to-cash with MuleSoft solution shows a worked design.

Error handling and idempotency

Retry only what can succeed on retry: timeouts, rate-limit responses and server errors, with exponential back-off and a cap. Do not retry validation errors; send them to the error queue for a person to fix. Make every write idempotent, for example by upserting on an external ID or passing an idempotency key, so a retry never creates a duplicate. Our integration error handling checklist goes further.

Trust boundaries and authentication

The gateway is the boundary for consumers. Each system API holds its own credential to its system, with least privilege. On Salesforce, use External Client Apps for inbound integrations, since connected apps support ends in Summer '27, and Named Credentials for outbound callouts. AI clients are consumers like any other; see the MCP security architecture.

Operational monitoring

Track request rates, error rates and latency per API, error queue depth and age, retry counts and end-to-end traces by correlation ID. Give each API and queue a named owner. Check Salesforce API consumption against your org's allocation in Salesforce documentation rather than assuming figures.

Alternative approaches and trade-offs

Point-to-point suits one or two stable links; compare in middleware vs point-to-point APIs. Event-driven designs decouple systems but need careful ordering and replay; see platform events for decoupled integrations. Low-code iPaaS tools such as MuleSoft Composer suit simple flows. Salesforce Connect shows external data without copying it, at the cost of depending on the external system.

Sources

• https://www.mulesoft.com/
• https://docs.mulesoft.com/mcp-connector/latest/
• https://blogs.mulesoft.com/news/mulesoft-26-mid-year-release-create-ai-experiences/
• https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_subscribe.htm
• https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm
• https://www.braze.com/docs/api/api_limits