Overview
Salesforce exposes its SOAP-based APIs through WSDL files. The two common WSDL types are the Enterprise WSDL and the Partner WSDL. Both let external systems integrate with Salesforce via SOAP, but they differ in how they model Salesforce metadata and how flexible they are for integrations across multiple orgs.
When to use which
Choose the WSDL type based on your integration requirements:
- Enterprise WSDL — Use when integrating with a single Salesforce org and you want strongly-typed objects. Ideal for server-to-server integrations where field definitions are stable.
- Partner WSDL — Use when building integrations that must work across many Salesforce orgs with different schemas. It’s loosely typed and more dynamic, suitable for middleware and tools that connect to multiple orgs.
Key differences
1. Type-safety and schema
Enterprise WSDL is strongly typed: it contains concrete definitions for all custom and standard objects and fields in your org. That means generated client classes map directly to your org-specific sObjects.
Partner WSDL is loosely typed: it uses a generic sObject type and represents fields as name/value pairs. Client code must handle fields dynamically (by name) rather than via generated properties.
2. Stability vs flexibility
Because Enterprise WSDL reflects your org schema, it can break client code if you change fields or objects (add/remove/rename). Partner WSDL is resilient to schema differences and can adapt at runtime by using API calls like describeSObjects.
3. Use-case and distribution
Enterprise WSDL is best for closed integrations where you control the Salesforce org (internal apps). Partner WSDL is best for ISVs, middleware, or integration layers that must support multiple customers with different schemas.
4. Generated code and language support
When you generate client code from the Enterprise WSDL (for Java, .NET, etc.), you get classes tailored to your org (e.g., Account, Custom_Object__c). From Partner WSDL, generated code typically provides a generic SObject class and utilities to access fields at runtime.
5. WSDL size and maintenance
Enterprise WSDLs are often larger because they list all objects/fields. Any metadata change requires regenerating the WSDL and client bindings. Partner WSDL is smaller and rarely needs regeneration when org schema changes.
6. Authentication and SOAP usage
Both WSDLs use the same login/authentication mechanism (SOAP login() / sessionId). The difference is how you pass and consume record data after authentication.
Example: Accessing fields
Using Enterprise WSDL (strong typing):
// pseudo-code
Account acc = soapClient.getAccountById("001xx000...");
String name = acc.getName();
Using Partner WSDL (dynamic):
// pseudo-code
SObject sobj = partnerClient.retrieve("Account", "001xx000...");
String name = sobj.getField("Name");
Summary (quick checklist)
- Use Enterprise WSDL for single-org, strongly-typed, performance-sensitive integrations.
- Use Partner WSDL for multi-org support, dynamic schemas, and middleware/ISV scenarios.
- Remember: Enterprise WSDL changes require regenerating client bindings; Partner WSDL is more resilient to metadata changes.
Related Salesforce API notes
Also evaluate Salesforce REST API and Bulk API for modern integrations — they can be simpler and more efficient for many use cases. But if your environment mandates SOAP or you need the operations exposed by the SOAP API, pick the WSDL that matches your schema stability and distribution needs.