Enterprise WSDL
The Enterprise WSDL is a Web Services Description Language (WSDL) document Salesforce generates per org that describes the SOAP API endpoints for that specific org's schema.
Definition
The Enterprise WSDL is a Web Services Description Language (WSDL) document Salesforce generates per org that describes the SOAP API endpoints for that specific org's schema. Unlike the Partner WSDL (which is generic and supports any org), the Enterprise WSDL embeds your org's exact field names, data types, and custom objects. This makes it strongly typed: code generated from an Enterprise WSDL knows that Account.Industry is a Picklist, that Opportunity.Amount__c is a Currency, and that your custom MyObject__c has these specific fields. The trade-off is that the Enterprise WSDL must be regenerated whenever the schema changes.
Salesforce orgs that integrate via SOAP API typically download the Enterprise WSDL once, generate strongly-typed client classes (in Java, .NET, Apex), and use those classes to call the API. The Enterprise WSDL is generated on demand from Setup, then API. For long-lived integrations with stable schemas, the Enterprise WSDL is the right choice; for tooling that must support many orgs, the Partner WSDL''s generic approach is necessary.
How the Enterprise WSDL works in Salesforce integration
Enterprise WSDL versus Partner WSDL
Salesforce generates two WSDLs for the SOAP API. The Enterprise WSDL is org-specific: it embeds every custom object, custom field, and picklist value from your org''s schema as a strongly-typed XML schema. Code generated from it has classes like Account, Account__c, MyCustom__c. The Partner WSDL is generic: it uses an SObject type with field-name-and-value pairs. Code from the Partner WSDL works against any org but loses compile-time type safety.
Generating the WSDL from Setup
In Setup, search for API. The page lists both WSDLs as download links. Click Enterprise WSDL to download the current version. The file is a generated XML document reflecting your org''s schema as of that moment. Saving the WSDL in your project''s resources is the standard practice; regenerating after schema changes is the maintenance pattern.
Generated client code and strongly typed APIs
Once the WSDL is in your project, language-specific tools generate client classes: wsimport (Java), wsdl.exe (.NET), Apex SOAP class generator. The generated classes have methods like createAccount() and updateOpportunity() with strongly-typed parameters. Compile-time safety means typos and field-mismatch bugs are caught at build time, not at runtime.
When the schema changes
Every time you add a field, change a field type, or rename an object in your Salesforce org, the Enterprise WSDL becomes out of date relative to the current schema. New fields are not exposed to existing code; removed fields cause runtime errors. The maintenance pattern: regenerate the WSDL, regenerate client classes, recompile, redeploy. For schemas that change weekly, this is impractical; for stable production schemas, it is fine.
API versioning and Salesforce releases
The WSDL is version-stamped: API version 60.0 (Summer 24) versus 61.0 (Winter 25) and so on. Salesforce releases three new API versions per year; the WSDL endpoint reflects the version your client code was compiled against. Old API versions remain supported for years. Code compiled against API v45 still works in 2026 even though many newer features are not available to it.
Use cases for Enterprise WSDL versus REST API
REST API is generally preferred for new development: simpler protocol, JSON payloads, faster client libraries. SOAP via Enterprise WSDL is still used for: legacy integrations that already use it, .NET environments where SOAP tooling is mature, scenarios needing strong typing at compile time, and high-volume batch operations where the Bulk API (which uses SOAP under the hood) is the right answer.
Generating WSDL for managed packages
Managed package developers can include the Enterprise WSDL or Apex callable interfaces in their packages. The Enterprise WSDL for a managed package exposes the package''s API surface to subscriber orgs. Subscribers can call package APIs through the WSDL, while package developers maintain backward compatibility across version bumps. This is how AppExchange apps expose programmatic access to their data and behavior.
How to download and use the Enterprise WSDL
Downloading the Enterprise WSDL is a few-click task in Setup. Using it to generate client code depends on your target language; the workflow is similar across .NET, Java, and Apex.
- Open the API page in Setup
Setup, then in the Quick Find box, type API. Click the API page.
- Click Generate Enterprise WSDL
The page lists two WSDL options: Enterprise and Partner. Click Generate Enterprise WSDL. A confirmation page warns about API-version selection; accept the default (current API version) unless you have a specific reason.
- Download the WSDL XML
The XML file downloads to your browser. Save it to your project''s resources folder. Rename if necessary to match your project''s conventions (enterprise-wsdl-v60.xml).
- Generate client classes in your language
For .NET: use wsdl.exe or svcutil.exe to generate proxy classes. For Java: use wsimport or the Apache CXF WSDL2Java tool. For Apex: use the Generate from WSDL link in the Setup UI (Apex Classes, then Generate from WSDL).
- Authenticate and call the API
Implement the login() call (or OAuth flow) to authenticate, then call the strongly-typed methods on the generated classes: salesforce.createAccount(myAccount); salesforce.updateOpportunity(myOpp). The generated classes handle WSDL-defined types and SOAP serialization.
- Test and deploy
Test the integration against a sandbox first. The Enterprise WSDL from sandbox should match the org''s schema. Deploy the generated client to production with caution; schema differences between sandbox and production produce runtime errors.
Strongly typed against this org''s schema. Best for stable schemas and compile-time safety.
Works across any org with SObject typing. Best for multi-org tooling.
JSON-based, simpler protocol. Preferred for new development.
In-org Apex methods exposed via SOAP. Generated by adding webservice keyword to methods.
- Enterprise WSDL is per-org. Code generated against one org''s WSDL will not work cleanly against another org. Multi-tenant tooling needs the Partner WSDL.
- Regenerating the WSDL requires regenerating client classes. Schema changes in the org cascade to the integration; budget time for both.
- Login flow for SOAP API is different from REST. SOAP uses login() returning a session ID; REST uses OAuth bearer tokens. Pick one model per integration.
- Salesforce deprecates very old API versions occasionally. Code compiled against API v8 (2008) eventually stops working; check API version end-of-life schedules.
Trust & references
Straight from the source - Salesforce's reference material on Enterprise WSDL.
- SOAP API Developer GuideSalesforce Developers
- Download Enterprise WSDLSalesforce Help
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 an Enterprise WSDL?
Q2. How is Enterprise WSDL different from Partner WSDL?
Q3. Should you build new integrations on Enterprise WSDL?
Discussion
Loading discussion…