A SOAP integration with Salesforce starts with downloading the right WSDL, generating client stubs, authenticating, and calling the operations you need. The steps below cover a typical end-to-end integration.
- Download the right WSDL
In Setup, go to API. Download the Enterprise WSDL for org-specific integrations or the Partner WSDL for generic ones. The Enterprise WSDL includes the org's exact schema; regenerate it after schema changes.
- Generate client stubs
Use your language's WSDL tooling: wsdl2java for Java, wsdl.exe for .NET, WSDL2Apex for Salesforce-to-Salesforce calls. The tool produces typed classes for each SOAP operation and message type.
- Authenticate with login()
Call the login() method with username, password (with security token appended if accessing from an untrusted IP), and the SOAP endpoint URL. The response includes a Session ID and the per-org SOAP endpoint to use for subsequent calls.
- Make CRUD calls within governor limits
Use the generated client to call create, update, query, search, or delete. Batch up to 200 records per call. For larger volumes, switch to the Bulk API or chunk the work into multiple SOAP calls.
- Handle SOAP faults and retry policies
Wrap each call in error handling that catches both HTTP-layer errors (timeout, network) and SOAP-layer faults (fault element in the response body). Implement exponential backoff for retryable errors like REQUEST_LIMIT_EXCEEDED.
Org-specific WSDL with typed elements for every field. Use for org-specific integrations that benefit from compile-time validation.
Generic WSDL that works against any Salesforce org. Use for AppExchange apps and tools that target multiple orgs.
Apex-side SOAP client generator for calling external SOAP services from inside Apex. The reverse of the typical SOAP API consumption pattern.
- SOAP CRUD operations cap at 200 records per call. Larger volumes need either multiple SOAP calls (slow) or the Bulk API (designed for volume). The cap is per-call; the total daily allowance is separate.
- The Enterprise WSDL is org-specific. Schema changes (new field, renamed field) require regenerating the WSDL and the client stubs in every consumer integration, or the integration will silently use stale type definitions.
- SOAP faults are inside the response body, not in the HTTP status code. Generic HTTP monitoring will report a faulting SOAP call as 200 OK; SOAP-aware monitoring must parse the body to detect the fault element.