Salesforce integrations rely on communication protocols that determine how external applications talk to your CRM data. While modern architectures favor lightweight, mobile-ready interfaces, legacy enterprise architectures demand strict contracts and strict data governance. The two primary protocols fulfilling these needs are REST (Representational State Transfer) and SOAP (Simple Object Access Protocol).
1. Understanding REST vs SOAP Architecture
Before diving into Salesforce-specific implementations, let us break down how each protocol operates:
- REST (Architectural Style): Operates entirely over standard HTTP/HTTPS protocols using standard verbs (
GET,POST,PATCH,DELETE). It delivers data primarily in lightweight JSON, making it ideal for web apps and low-bandwidth scenarios. - SOAP (Standardized Protocol): Relies strictly on XML payloads structured with envelopes, headers, and bodies. It uses a formal contract called a
WSDL(Web Services Description Language) to enforce strict schema validation on every call.
- Data Formats: REST supports JSON, XML, and plain text; SOAP supports strictly XML.
- Contract Binding: REST is loosely coupled (Swagger/OpenAPI optional); SOAP is tightly bound via static
Enterprise WSDLorPartner WSDLfiles. - Authentication: REST uses OAuth 2.0; SOAP uses a session ID header generated via an initial login handshake.
- Governance Limits: Both count toward your 24-hour total Salesforce API request allocations.
2. Integrating with Salesforce REST API
The standard Salesforce REST API exposes simple URI endpoints to access records, execute SOQL queries, and inspect metadata. Custom REST endpoints can also be created in Apex using the @RestResource annotation.
Exposing a service to fetch Account details via a simple GET request:
@RestResource(urlMapping='/v1/AccountService/*')
global with sharing class AccountRestService {
@HttpGet
global static Account getAccountById() {
RestRequest req = RestContext.request;
String accountId = req.requestURI.substring(req.requestURI.lastIndexOf('/') + 1);
return [SELECT Id, Name, Industry, AnnualRevenue FROM Account WHERE Id = :accountId LIMIT 1];
}
}- Lightweight Payloads: JSON structure minimizes network overhead, speeding up response times for high-volume consumers.
- State-of-the-art Security: Native integration with Connected Apps and standard OAuth flows (such as JWT Bearer or Web Server flow).
- Broad Compatibility: Native parsing across JavaScript frameworks, mobile SDKs, and modern middleware like MuleSoft.
3. Leveraging the Salesforce SOAP API
The Salesforce SOAP API is purpose-built for enterprise workflows that demand rigid schema verification. Salesforce provides two primary WSDL files:
- Enterprise WSDL: Strongly typed and bound to a specific Salesforce org's unique schema (including custom fields). Changes in org metadata require generating and importing a new WSDL.
- Partner WSDL: Loosely typed and dynamic. Designed for multi-tenant integrations and AppExchange packages that must interface across different customer schemas.
4. Decision Matrix: Which Protocol Should You Choose?
- Select REST if: You are building SPAs (Single Page Applications), mobile apps, connecting modern microservices, or aiming to minimize payload size over the wire.
- Select SOAP if: Your external system is an enterprise ERP (like SAP or Oracle financials) that enforces strict WSDL validation or requires end-to-end XML transactional safety.
- Use a Hybrid Model when necessary: Fetch data from external microservices via REST, but publish structured events or trigger enterprise transactions into Salesforce via SOAP.
Summary
Both REST and SOAP provide secure, scalable channels to integrate external systems with Salesforce. By aligning the integration architecture with payload complexity, client requirements, and contract stability, you can ensure high performance and reliable data exchange across your entire tech stack.