Calling the SOAP API rarely involves writing raw XML these days. Modern integrations consume the WSDL into their integration platform or generate client code in their language of choice. The work is in choosing the right WSDL, configuring authentication, handling per-record results, and migrating off deprecated username-password flows where applicable.
- Decide between Enterprise and Partner WSDL
Enterprise for bespoke integration with one specific org. Partner for ISV tools that ship to many customers. Most internal IT projects use Enterprise; tools sold on AppExchange or built for multi-tenant use cases use Partner.
- Download the WSDL from Setup
Setup > API > Generate Enterprise WSDL or Generate Partner WSDL. Save the XML to your project. Re-download after schema changes (custom fields added) to keep the strongly-typed Enterprise WSDL in sync with the org.
- Generate client code from the WSDL
Use your integration platform''s WSDL consumption tooling, or generate language-specific client code. MuleSoft, Informatica, and similar platforms handle this with a few clicks. For custom code, use wsdl2java for Java, dotnet-wsdl for .NET, or zeep for Python.
- Configure OAuth authentication
Create a Connected App with OAuth scopes (api, refresh_token at minimum). Configure your client with the OAuth credentials. Use JWT Bearer flow for server integrations or Web Server flow for user-facing integrations.
- Make a test call to verify connectivity
Call a simple operation like getUserInfo() or describeGlobal() to confirm authentication and connectivity. The response tells you which org and user you are connected as. This is the integration smoke test.
- Build the integration logic with batch operations
Use create(), update(), upsert(), delete() with batches up to 200 records. Set AllOrNone=false for fault tolerance. Process the per-record SaveResult to log failures separately from successes.
- Implement retry and error handling
Per-record errors are returned in SaveResults. SOAP faults indicate network or authentication failures. Build retry with exponential backoff for transient faults; log per-record errors to a tracking system for manual review.
- Migrate any login() calls to OAuth
Setup > Connected App > switch authentication from username-password to OAuth. The login() operation is deprecated and being phased out. New integrations should not use it; legacy integrations should be migrated during planned maintenance.
Enterprise for one-org strongly-typed integration. Partner for multi-org generic integration used by ISVs.
OAuth is the modern standard. The login() username-password operation is deprecated and being phased out.
Controls whether one record failure rolls back the whole batch (true) or only the failing record (false). Most integrations want false.
- The login() operation is deprecated and will be retired. New integrations must use OAuth; existing integrations should plan migration before the end-of-life date.
- Enterprise WSDL is org-specific. After custom fields are added or relationships change, re-download the WSDL or the strongly-typed client code falls out of sync.
- Each SOAP operation caps at 200 records per call. For higher volume, use Bulk API 2.0 instead of looping SOAP calls.
- Multi-Factor Authentication enforcement blocks username-password integrations for impacted users. Confirm the integration user is exempted (rare and discouraged) or migrate to OAuth.
- SOAP API call counts against the daily API limit just like REST. Combined with REST traffic, monitor total consumption to avoid blowing the cap.