Quick overview
Salesforce exposes SOAP-based APIs via WSDL files. Two common WSDLs are the Enterprise WSDL and the Partner WSDL. Both let external applications integrate with Salesforce, but they differ in typing, flexibility, and typical use cases. Understanding the differences helps you choose the right integration strategy for your project.
Key differences
1) Strongly-typed vs loosely-typed
The Enterprise WSDL is strongly typed — it contains concrete XML schema for the objects and fields in a specific Salesforce org. When you generate client stubs from an Enterprise WSDL, the generated classes map directly to your org’s object model (Account, Contact, custom fields, etc.).
The Partner WSDL is loosely typed (generic). It uses a generic sObject type and describes objects and fields at runtime. Client code uses name/value pairs rather than concrete generated classes.
2) When to use each
Enterprise WSDL is best when:
- Your integration is tightly coupled to a single Salesforce org.
- You want compile-time type safety and generated classes for objects/fields.
- You prefer object-oriented calls using concrete types produced by client stub generators.
Partner WSDL is best when:
- You need a single integration that works across multiple Salesforce orgs with different schemas.
- Your integration requires dynamic discovery of objects and fields (via
describeSObjects()). - You prefer a flexible, metadata-driven approach that handles schema changes without regenerating the WSDL.
3) Handling custom fields and schema changes
Enterprise WSDL includes definitions for custom fields present at the time the WSDL was generated. If you add or change fields in the org, you must regenerate the Enterprise WSDL and update client stubs to get the new types.
Partner WSDL doesn’t include per-org custom field types — since it uses the generic sObject, it relies on runtime metadata calls. That makes it resilient to schema changes without needing to regenerate the WSDL.
4) Generated code / developer experience
Enterprise WSDL gives you nice generated classes and compile-time checks (e.g., Account.getName()). This reduces runtime errors and makes development straightforward in strongly-typed languages like Java or C#.
Partner WSDL requires handling generic records and name/value maps, which can be slightly more verbose but more flexible for multi-org integrations or middleware/ETL tools.
5) Performance and payload size
Both WSDLs use the same underlying Salesforce SOAP endpoints and API operations, so runtime performance is similar. The difference is on the client side: Enterprise stubs may have larger generated code size because they include all object/type schemas, whereas Partner clients are smaller and more dynamic.
6) Example (conceptual)
Enterprise WSDL generated type (conceptually):
<complexType name="Account">
<sequence>
<element name="Id" type="xsd:string"/>
<element name="Name" type="xsd:string"/>
<element name="Custom_Field__c" type="xsd:string"/>
</sequence>
</complexType>
Partner WSDL uses a generic sObject payload at runtime (name/value pairs):
<sObject>
<type>Account</type>
<fieldsToNull/>
<any>
<field name="Name">Acme Corp</field>
<field name="Custom_Field__c">Value</field>
</any>
</sObject>
7) Authentication & endpoint
Both use the same SOAP login and session pattern. After login, you use the returned server URL and session ID for subsequent calls. The difference lies only in the WSDL typing, not in authentication flows or endpoints.
8) When not to use WSDLs
If you’re building new integrations, consider using the Salesforce REST APIs (including Composite and Bulk REST) or the robust SOAP-based SOAP API but accessed via modern SDKs. REST is often easier for lightweight integrations and microservices.
Which should you choose?
Choose the Enterprise WSDL when you control the Salesforce org and want strong typing and generated client classes. Choose the Partner WSDL when building middleware or integrations that must work across multiple orgs, or when you need a metadata-driven, dynamic integration.
Quick checklist
- Single-org & compile-time safety → Enterprise WSDL
- Multi-org or dynamic schema → Partner WSDL
- Need to avoid regenerating stubs after schema changes → Partner WSDL
- Prefer generated classes and type safety → Enterprise WSDL
Understanding these trade-offs will help you design robust, maintainable Salesforce integrations.