Salesforce Integration Guide: REST vs SOAP

Almost no real Salesforce implementation exists in isolation — it connects to ERPs, marketing platforms, shipping systems, payment gateways, and more. Understanding integration fundamentals is essential for any serious Salesforce Developer.

REST vs. SOAP: The Core Difference

REST (Representational State Transfer) is an architectural style using standard HTTP methods (GET, POST, PUT, DELETE) and typically JSON payloads. It's lightweight, human-readable, and the dominant standard for modern APIs.

SOAP (Simple Object Access Protocol) is a stricter, XML-based protocol with a formal contract (WSDL) defining exactly what operations are available. It's more rigid but was historically favored by large enterprise systems for its strict typing and built-in error handling standards.

In practice: most new integrations use REST. SOAP mainly comes up when integrating with older enterprise systems (some ERPs, legacy banking/finance systems) that only expose SOAP endpoints.

Salesforce Calling Out (Apex Callouts)

When Salesforce needs to fetch or send data to an external system, Apex makes an HTTP callout:

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Named_Credential/orders');
req.setMethod('GET');
Http http = new Http();
HttpResponse res = http.send(req);
if (res.getStatusCode() == 200) {
    // parse res.getBody(), typically JSON
}

Note the callout:My_Named_Credential syntax — this references a Named Credential, which securely stores the actual endpoint URL and handles authentication, so it's never hardcoded in Apex.

External Systems Calling Into Salesforce

External systems can read/write Salesforce data via:

• Salesforce's standard REST API — generic CRUD operations on any object
• Custom Apex REST endpoints — you define your own endpoint and logic using @RestResource, useful when you need custom business logic on the way in, not just raw CRUD
• Bulk API — optimized for large-volume data operations
• Streaming API / Platform Events / Change Data Capture — for event-driven, near-real-time integration patterns rather than request/response

Authentication Patterns

Most modern integrations use OAuth 2.0 — Named Credentials in Salesforce can handle this automatically for outbound callouts, managing token refresh without custom Apex code. For inbound access, external systems authenticate against Salesforce using a Connected App with OAuth.

Common Integration Mistakes

1. Hardcoding endpoints and credentials in Apex instead of using Named Credentials — a security and maintainability problem.
2. Not handling callout failures gracefully — external systems go down; your Apex should handle timeouts and error responses, not assume every callout succeeds.
3. Making synchronous callouts from triggers directly — Apex triggers can't make synchronous callouts at all (a governor-limit-related restriction); you need to defer to an asynchronous context (like a Queueable) instead.
4. Ignoring API limits — both Salesforce's own API call limits and the external system's rate limits need to be respected in your integration design.
5. Not planning for bulk volumes — an integration that works for a single test record can fail under real bulk data volumes if it wasn't designed with governor limits in mind. See our Governor Limits guide.

Where Integration Fits in Agentforce

Modern Agentforce agents frequently use integration patterns as actions — for example, an agent checking real-time shipment status via an external API callout. Solid integration fundamentals directly carry over into building good AI agent actions, which is one more reason this remains a core Developer skill even as AI capabilities expand. See Agentforce Explained.

Learning Integration Hands-On

Integration is best learned by building a real callout against a real (or sandboxed) external API — not just reading about the syntax. It's covered as a dedicated module in our Salesforce Developer Training course.