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.