Partner WSDL
A Partner WSDL is a Salesforce-provided WSDL file that describes the SOAP API in a generic, loosely typed way, so a single client application can call any Salesforce org without being rebuilt for each one.
Definition
A Partner WSDL is a Salesforce-provided WSDL file that describes the SOAP API in a generic, loosely typed way, so a single client application can call any Salesforce org without being rebuilt for each one. Instead of baking in a specific org's objects and fields, it represents every record as a generic sObject and treats fields as name-value pairs. This makes it the standard choice for AppExchange partners and ISVs whose product talks to many different customer orgs.
A Partner WSDL stands in contrast to the Enterprise WSDL, which is strongly typed and tied to one org's exact schema. With the Partner WSDL you download and consume the file once per API version, then discover each org's fields at runtime with describe calls. You trade some compile-time convenience for the ability to write one code base that works everywhere.
How the Partner WSDL trades strong typing for portability
Loosely typed by design
The defining trait of the Partner WSDL is that it is loosely typed. The Enterprise WSDL bakes every standard and custom object into the file as a strongly typed class, so Account, Contact, and your custom My_Object__c each become a distinct type with named, typed fields. The Partner WSDL does none of that. It declares one generic sObject type with a type attribute (the API name of the object) and a collection of fields expressed as name-value pairs. Field values cross the wire as strings rather than as typed properties. That sounds like a downside, and in day-to-day coding it does cost you something. You lose IntelliSense and compile-time checks, and you have to read and write values as text. The upside is portability. Because the file never names a specific object or field, it does not change when a customer adds a custom field or installs another package. One consumed Partner WSDL describes the shape of the API itself, not the shape of any one org's data model.
Built for ISVs and many orgs
The Partner WSDL exists because partners face a problem customers do not. A customer building an internal integration knows their own schema and can rely on the Enterprise WSDL, which mirrors that schema exactly. An ISV shipping a product on AppExchange has no idea what objects or fields any given subscriber org contains. Generating a separate strongly typed WSDL per customer, then recompiling for each, would not scale. The Partner WSDL solves this with one generic contract. The same compiled client connects to org A, org B, and org C, reading whatever objects each one exposes. This is why Salesforce documents the Partner WSDL as the recommended file for partner and ISV development, and why integration vendors who build connectors for the broader Salesforce market reach for it. If your code base has to run against orgs you have never seen, the Partner WSDL is the file that makes that possible without a rebuild for every install.
Consume once per API version
A practical benefit follows from the loose typing. Because the Partner WSDL does not encode any org's fields, you download and consume it only once for a given API version. Whenever a Salesforce org adds or changes objects and fields, an Enterprise WSDL integration has to regenerate and re-consume the file to pick up those changes. The Partner WSDL integration does not, since field discovery happens at runtime rather than at build time. This stability is worth real money in maintenance terms. A connector built on the Partner WSDL keeps working as subscriber orgs evolve their schemas, with no redeploy on the partner's side. You still upgrade deliberately when you want newer API features, but that is a version bump on your schedule, not a forced reaction to a customer's configuration change. The decoupling between your client and the customer's data model is the whole point, and it is what lets a single release serve thousands of orgs at once.
Working with generic sObjects
Coding against the Partner WSDL means handling the generic sObject directly. To create or update a record, you instantiate an sObject, set its type to the object's API name (for example Account), and populate a fields collection with the field API names and their string values. To clear a value, you add the field name to the fieldsToNull array rather than passing an empty value. When a query returns records, you read each result the same way, pulling values out of the generic fields collection by name. Because nothing is strongly typed, you cannot assume a field exists. The companion habit is calling describeSObjects (or describeGlobal) to learn which objects and fields the current org actually has, along with their data types and permissions. Your code inspects that metadata, then reads and writes only fields it has confirmed are present. It is more defensive code than the Enterprise path, but it is the price of running safely against orgs whose schemas you do not control.
Partner WSDL versus Enterprise WSDL
The choice between the two files comes down to a single question: how many different orgs will this code base talk to? For one known org, the Enterprise WSDL is usually the easier path. It is strongly typed, so you get named fields, compile-time safety, and editor autocomplete, and customer-specific integration teams tend to prefer it. The cost is that it is tied to that org's exact configuration and must be regenerated when the schema changes. For many orgs, the Partner WSDL wins despite being harder to code against. Its generic contract is the only one that survives unknown and shifting schemas without a rebuild. A useful rule of thumb: if you control the org, lean Enterprise; if your customers control the orgs, lean Partner. Both files describe the same SOAP API and expose the same core calls such as query, create, update, and delete. They differ only in how strictly they type the data those calls carry.
Where SOAP and REST fit today
The Partner WSDL is part of the SOAP API, which remains fully supported and is still common in established ISV products and enterprise middleware. WSDL-driven SOAP clients suit strongly governed environments and toolchains that already speak SOAP, and the Partner WSDL keeps those clients portable across customer orgs. For new build-from-scratch integrations, many teams now start with the REST API instead. REST avoids WSDL generation entirely, returns lightweight JSON, and pairs naturally with modern web and mobile clients. It also offers its own metadata and describe resources, so the runtime field discovery that the Partner WSDL relies on has a REST equivalent. The honest framing is that the Partner WSDL is not retired or deprecated; it is a mature, dependable tool with a clear niche. If you are extending a SOAP-based product or need the SOAP contract for a specific reason, the Partner WSDL is the right file. If you are greenfield and org-agnostic, weigh REST first and reach for the Partner WSDL when SOAP is the requirement.
How to generate and use the Partner WSDL
You do not build a Partner WSDL by hand. Salesforce generates it for you from Setup, and you download the file once per API version, then feed it to your SOAP toolkit to generate client stubs. Here is the path in a Lightning org.
- Open the API page in Setup
From Setup, type API into the Quick Find box and click API. This page lists every WSDL and client certificate Salesforce can generate for your org.
- Generate the Partner WSDL
Click Generate Partner WSDL. Salesforce builds a generic, loosely typed WSDL that does not reference your org's specific objects or fields, so the same file works against any org.
- Save the file locally
Right-click the generated page and save it with a .wsdl extension. Keep it under version control alongside your client so you know exactly which API version your stubs were built from.
- Generate client stubs
Feed the .wsdl into your platform's SOAP tooling (for example wsimport for Java or the Force.com WSC) to produce the sObject and binding classes your application calls.
Produces the generic, loosely typed file for cross-org and ISV use. Download and consume it once per API version.
Produces the strongly typed file bound to this org's exact schema. Choose this for a single, known org instead of the Partner WSDL.
The user generating or calling the WSDL needs API Enabled. Without it, SOAP API access is blocked regardless of which WSDL you downloaded.
- Because field values arrive as strings, your code must parse and format types (dates, numbers, booleans) itself rather than relying on typed properties.
- Never assume a field exists. Call describeSObjects at runtime to confirm objects and fields before reading or writing them across unknown orgs.
- Use the fieldsToNull array to clear a field with the Partner WSDL; sending an empty value in the fields collection does not reliably null it out.
- The generated WSDL is pinned to one API version. Regenerate it deliberately when you want newer features, not in reaction to a customer's schema change.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Partner WSDL.
Hands-on resources to go deeper on Partner WSDL.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Partner WSDL?
Q2. How does it differ from Enterprise WSDL?
Q3. When is Partner WSDL the right choice?
Discussion
Loading discussion…