Quick overview
Salesforce exposes its SOAP API through WSDL files. The two most commonly used WSDLs are the Enterprise WSDL and the Partner WSDL. Both let external applications call Salesforce SOAP APIs, but they differ in typing, stability, and intended use-cases. Understanding their differences helps you choose the correct integration pattern for long-term maintainability and portability.
Enterprise WSDL — strongly typed, org-specific
The Enterprise WSDL is a strongly typed WSDL generated for a single Salesforce organization. It includes concrete definitions for the sObjects and fields present in that org at the time the WSDL is generated. This produces a stable API surface for that specific org and is useful when your consumer code knows the exact object schema and will not need to support multiple orgs with different schemas.
Partner WSDL — loosely typed, portable
The Partner WSDL is a loosely typed (untyped) WSDL that uses generic sObject structures. Instead of concrete classes for each Salesforce object, it exposes a generic sObject type whose fields are represented at runtime. This makes the Partner WSDL ideal for building client applications that must integrate with multiple Salesforce orgs or support changing schemas.
Key differences
Typing
Enterprise WSDL: strongly typed (classes generated for each sObject). Partner WSDL: loosely typed (generic sObject).
Stability and regeneration
Enterprise WSDL is org-specific. If you add, remove, or rename fields or objects in the org, you must regenerate the Enterprise WSDL and recompile client stubs. Partner WSDL is more resilient to schema changes because it resolves fields at runtime.
Portability
Enterprise WSDL is tailored to a single org—less portable. Partner WSDL is portable across orgs and ideal for multi-tenant connectors or middleware that talks to different Salesforce instances.
Client code and tooling
With Enterprise WSDL, client code can be simpler and safer because you get typed classes and compile-time validation. With Partner WSDL, client code must handle field names and types dynamically (for example, parsing field maps on each sObject).
WSDL size
Enterprise WSDL can become very large for orgs with many custom objects/fields. Partner WSDL is comparatively compact because it uses generic structures.
Common use-cases
Use Enterprise WSDL when you control the Salesforce org and the schema is stable — e.g., single-org integrations, internal applications with static data model. Use Partner WSDL when building integrations that must connect to multiple customer orgs, or when you need a resilient adapter that tolerates schema variability.
Authentication and endpoints
Both WSDLs use the same SOAP API endpoints and authentication patterns (username/password + security token or OAuth session). Example SOAP login endpoint (same for both):
https://login.salesforce.com/services/Soap/u/57.0
How to generate
In Salesforce Setup, search for “API” or “Integrations” and choose the WSDL generator. Then download either the Enterprise WSDL or the Partner WSDL. Remember: if you regenerate an Enterprise WSDL after schema changes, update and recompile your client code.
Recommendation
If you need strong typing and are integrating with a single, controlled org, choose the Enterprise WSDL. If you build middleware or tools that must work across many orgs or want to avoid frequent client regeneration, choose the Partner WSDL. For modern integrations, consider REST APIs or Salesforce’s SOAP-based Bulk and Metadata APIs when appropriate.