You do not create a WSDL by hand. You generate and download it from Setup, then import it into your development tool to produce client code. Here is the path for the Enterprise and Partner WSDLs.
- Open the API page in Setup
From Setup, enter API in the Quick Find box, then under Integrations select API. This page lists every downloadable WSDL and the client certificate options.
- Pick the right WSDL
Choose Generate Enterprise WSDL for a strongly typed file tied to your org, or Generate Partner WSDL for a generic file that works across orgs. Metadata, Apex, and Tooling WSDLs are listed here too.
- Generate and save the file
For the Enterprise WSDL, confirm the package version prompt, then click Generate. The browser shows the XML, which you save with a .wsdl extension to a known folder.
- Import it into your tool
Feed the saved file to a code generator such as wsdl2java, Apache Axis, or a Visual Studio service reference. The tool builds typed classes and method stubs you call from your app.
- Regenerate after schema changes
When you add custom objects or fields, regenerate the Enterprise WSDL and refresh your client so the new metadata is available. Partner WSDL clients address fields by name and need no regeneration.
Strongly typed and specific to your org, with custom objects and fields as concrete types. Best when you target one known org and want compile-time checking.
Loosely typed and generic, using a flexible sObject and field name and value pairs. Best for ISV and AppExchange apps that run in many customer orgs.
Backs the Metadata API deploy and retrieve calls for moving configuration between orgs as file based packages. Used by build and release tooling.
An optional certificate you download here to authenticate outbound callbacks like outbound messages or delegated authentication endpoints.
- The Enterprise WSDL goes stale the moment you change metadata. Forgetting to regenerate it is the top reason a new field is missing from your client code.
- Log in to your My Domain login URL and reuse the session ID and server URL from the login response. Pointing later calls at the wrong instance returns INVALID_SESSION_ID errors.
- Each WSDL is pinned to an API version. A feature from a newer release will not appear until you regenerate the WSDL at that version and rebuild.