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

Salesforce integration is one of the highest-leverage decisions in any implementation. A well-chosen integration pattern scales gracefully, tolerates failures, and is maintainable by the team long after the initial developer has moved on. A poorly chosen pattern becomes a fragile bottleneck that breaks under load and requires specialist knowledge to debug.

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 has robust query support through the SOQL endpoint.

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
Streaming API or CometD to receive events.

Summer '26 added ordering guarantees and dead letter queues to Platform
Events — a long-requested feature that makes them suitable for
high-reliability integration scenarios where event sequence matters.

### 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 Streaming API and receive real-time change events
as records are created, updated, deleted or undeleted.

## Summer '26: Salesforce MCP Server GA

Model Context Protocol servers became generally available in Summer '26.
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.