Salesforce Integration Patterns — REST, SOAP, Platform Events and More

Pick the wrong integration pattern and you find out in production, usually as a synchronous callout timing out under load and rolling back the user’s save. The choice you make early (REST, SOAP, Platform Events, Change Data Capture) sets the failure modes you will live with for years. A pattern that fits the direction, timing, and volume of the traffic keeps running after the original developer has moved on. One that fights those three constraints becomes the thing nobody wants to touch.

The integration decision framework

Start with direction. Is an external system calling Salesforce, or is Salesforce calling an external system? Then consider timing — does the calling system need an immediate response, or can it fire and forget? Then consider volume — one record at a time, or thousands per minute?

Inbound integration patterns

Salesforce REST API

The standard REST API at /services/data/vXX.X/ is the first choice for inbound integrations where an external system needs to read or write Salesforce records. It is well-documented, supports all CRUD operations, and lets you run arbitrary SOQL through the query endpoint, including relationship queries and aggregate functions.

For external systems that need to perform multiple related operations, the Composite REST API allows up to 25 subrequests in a single HTTP call with response chaining — the result of one request can be used as input to the next.

Apex REST

When the standard REST API cannot express the required data shape or business logic, build a custom endpoint using @RestResource. This gives you full control over request parsing, data transformation, and response format.

@RestResource(urlMapping='/v1/case-intake/*')
global class CaseIntakeService {
@HttpPost
global static CaseIntakeResponse createCase() {
RestRequest req = RestContext.request;
CasePayload payload = (CasePayload)JSON.deserialize(
req.requestBody.toString(),
CasePayload.class
);
// business logic here
Case c = new Case(Subject = payload.subject, Status = 'New');
insert c;
return new CaseIntakeResponse(c.Id, 'created');
}
}

Outbound integration patterns

Apex callouts

For synchronous outbound calls where Salesforce needs an immediate response from an external system, Apex HTTP callouts using HttpRequest and HttpResponse are the standard approach. Always use named credentials rather than hardcoded URLs to manage authentication and endpoints in a deployment-safe way.

Platform Events

When Salesforce needs to notify an external system but does not need an immediate response, Platform Events are the right choice. Events are published within the Salesforce transaction and delivered asynchronously to subscribing systems. External subscribers use the Pub/Sub API (gRPC, with flow control) or the older CometD Streaming API.

Salesforce publishes each event to the bus once and does not retry on the publisher side; a subscriber that was offline recovers by replaying from its last ReplayId within the 72-hour retention window. Ordering is only guaranteed within a single publish call, and there is no platform-side dead-letter queue — a subscriber that cannot process an event has to park it itself. The Platform Events reliability guide covers exactly where messages can be lost and how to design around it.

Change Data Capture

For external systems that need to stay in sync with Salesforce data, Change Data Capture eliminates the need for polling. Subscribe to CDC channels via the Pub/Sub API and receive real-time change events as records are created, updated, deleted or undeleted.

Salesforce Hosted MCP Servers

Salesforce Hosted Model Context Protocol servers became generally available in April 2026 for Enterprise Edition and above. This opens a new category of AI-driven integration — external AI tools including Claude, GitHub Copilot and others can access Salesforce data and metadata as context using the standardised MCP interface.

For integration architects, this means Salesforce is becoming natively accessible to AI tooling without custom API development. The immediate use case is AI assistants that can query Salesforce data as part of broader workflows. The longer-term implication is that AI-to-Salesforce integration becomes a standard capability rather than a bespoke development effort.

The reliability principles

Every production integration should be idempotent — sending the same message twice should produce the same result as sending it once. Use upsert with an external ID field rather than insert to achieve this.

Build for failure. External systems are unavailable. Implement retry logic with exponential backoff. Use Platform Events or Queues as buffers when synchronous reliability is required. Store failed payloads in a custom object for manual review and replay.

Monitor everything. Log every callout with its response code and response time. Set up alerts for error rates above 1%. A silent integration failure is worse than a visible one.