Quick overview
When integrating with Salesforce via SOAP API you’ll encounter two main WSDL types: the Enterprise WSDL and the Partner WSDL. They both expose Salesforce SOAP endpoints but differ in typing, stability, and use-cases. Choosing the right WSDL affects client generation, maintenance effort, and compatibility across Salesforce orgs.
Key differences
1. Strong typing vs. dynamic typing
The Enterprise WSDL is strongly typed and generated for a specific org’s schema. It contains concrete SObject definitions (fields and data types) so generated client classes map directly to your org’s objects and fields. This makes development easier and safer when your integration is tightly coupled to a particular org.
The Partner WSDL is loosely (dynamically) typed. It uses a generic sObject representation where fields are name/value pairs. This makes the partner WSDL flexible and suitable for integrations that must work across multiple orgs with different schemas.
2. When to use each
Use Enterprise WSDL when:
– Your integration targets a single Salesforce org.
– You want strongly typed client code generated by tools (e.g., Java, .NET).
– You want compile-time mapping of fields and objects.
Use Partner WSDL when:
– You need one integration to work across many Salesforce orgs with different customizations.
– You prefer dynamic handling of fields at runtime using the generic sObject.
3. Maintenance and stability
The Enterprise WSDL is tied to the org’s metadata. When fields or object names change (for example, adding/removing custom fields), the Enterprise WSDL changes and client stubs may need to be regenerated and redeployed. This can increase maintenance work.
The Partner WSDL is more stable across orgs because it doesn’t hard-code specific field definitions. Schema changes in an org generally don’t require regenerating client code—your integration reads fields dynamically.
4. Generated client code and usability
Enterprise WSDL leads to generated classes with concrete types (e.g., Account with typed fields). This yields better IDE support and safer code but reduces portability.
Partner WSDL generates generic classes (e.g., sObject) where fields are accessed via a map-like API (get/set by name). Less compile-time safety, but more flexible.
5. Use with Metadata-driven or Multi-Org integrations
For metadata-driven tools, middleware, or ISV products that must connect to many customer orgs, the Partner WSDL is usually preferred. For tightly integrated, single-org enterprise applications, the Enterprise WSDL is typically better.
6. SOAP Headers & session handling
Both WSDLs use the same SOAP API endpoints and session-based authentication (login() returns a sessionId used in the SOAP header). Example SOAP header usage (same for both):
<soapenv:Header>
<SessionHeader xmlns="urn:partner.soap.sforce.com">
<sessionId>00D...!AQMAQ...</sessionId>
</SessionHeader>
</soapenv:Header>
7. Namespaces
The namespace in the WSDL differs: the Enterprise WSDL uses an org-specific namespace (reflecting your org’s WSDL target namespace), while the Partner WSDL uses a generic namespace (typically urn:partner.soap.sforce.com or similar). This contributes to the Enterprise WSDL’s tight coupling to an org.
Summary — Which to choose?
– Choose Enterprise WSDL for single-org integrations where strong typing and IDE support matter.
– Choose Partner WSDL for integrations that must be portable across multiple orgs or for middleware/ISV solutions that must handle varying schemas dynamically.
Keywords: Salesforce WSDL, Enterprise WSDL, Partner WSDL, SOAP API, sObject, integration, typed vs dynamic.