Overview
Salesforce exposes SOAP-based APIs via WSDL files. Two common WSDLs you’ll encounter are the Enterprise WSDL and the Partner WSDL. Both enable programmatic access to Salesforce, but they differ in schema rigidity, typing, portability, and typical use-cases. Understanding the differences helps you pick the right integration approach for your project.
1. Typed vs. Untyped (Strong vs. Loose Schema)
The Enterprise WSDL is strongly typed. It includes concrete object and field definitions specific to your org (e.g., Account, Custom_Object__c, Field API names). The generated client has model classes that match your org’s schema.
The Partner WSDL is loosely typed (untyped). It uses generic sObject and field name/value pairs, allowing the same WSDL to work against multiple orgs with different schemas.
2. When to Use Each
Enterprise WSDL is best when:
- You control the Salesforce org and the schema won’t change frequently.
- You want strongly-typed client stubs and compile-time schema checks.
- You build a single integration tightly coupled to one org.
Partner WSDL is best when:
- You need a single integration that works across many customer orgs (ISV apps).
- The target orgs may have different custom fields or objects.
- You prefer runtime handling of fields using generic sObjects.
3. Stability and Maintenance
Enterprise WSDL clients break if the Salesforce schema changes (fields or objects removed/renamed). Any schema change generally requires re-generating client code from the new WSDL and redeploying the integration.
Partner WSDL clients are more resilient to schema changes because they work with generic sObject structures. You handle fields dynamically at runtime, so changes in the target org usually don’t require regenerating client stubs.
4. Generated Code & Developer Experience
Enterprise WSDL generates strongly-typed classes in your language (e.g., Java, C#), which is great for IDE support, autocomplete, and compile-time checks.
Partner WSDL generates generic sObject wrappers; you manipulate records with name/value maps. This increases runtime flexibility but reduces compile-time safety.
5. Performance and Payload Size
Enterprise WSDL-based calls may include more concrete types and result in slightly larger client binaries, but runtime performance is comparable. Partner WSDL can produce smaller WSDL files (single generic sObject definition) and fewer client classes, but you pay the cost of more runtime field lookups and casting.
6. Example Use-Cases
Enterprise WSDL:
// Java pseudo-example showing typed use
Account acct = new Account();
acct.setName("Acme");
acct.setCustom_Field__c("Value");
SaveResult[] res = binding.create(new SObject[] {acct});
Partner WSDL:
// Java pseudo-example showing untyped use via sObject
SObject acct = new SObject();
acct.setType("Account");
acct.setFields(new XmlObject[] { new XmlObject("Name","Acme"), new XmlObject("Custom_Field__c","Value") });
SaveResult[] res = binding.create(new SObject[] {acct});
7. Session and Login Differences
Both WSDLs use the same SOAP login and session handling. The difference is how you handle returned records: enterprise clients map fields to typed properties, partner clients give a dynamic map of fields.
8. Best Practices
- For single-org, internal integrations prefer Enterprise WSDL for strong typing and developer productivity.
- For multi-tenant or ISV integrations prefer Partner WSDL to support variable schemas across customer orgs.
- Keep WSDL-generated client code under version control and document any re-generation steps when the org schema changes.
- Consider using the REST API or Bulk API for newer integrations — they can be easier to maintain and often simpler to work with than SOAP WSDLs.
Summary
In short: Enterprise WSDL = strongly-typed, org-specific, ideal for stable single-org integrations. Partner WSDL = loosely-typed, flexible across orgs, ideal for ISVs and multi-tenant integrations. Choose based on coupling, maintenance, and whether compile-time safety matters for your project.