Generating the Metadata WSDL and importing it into a development platform is a one-time setup you do before building a SOAP client. You download the file from Setup, generate stub code from it, and pair it with a login WSDL for authentication.
- Open the API page in Setup
From Setup, enter API in the Quick Find box, then select API. This page lists every WSDL and client certificate Salesforce can generate for your org.
- Generate the Metadata WSDL
Click Generate Metadata WSDL and save the XML file to your file system. The file is tied to the org's current API version, so note that version for later.
- Generate a login WSDL
Back on the API page, also generate the Enterprise WSDL or Partner WSDL. You need its login operation to obtain the session ID that the Metadata API requires.
- Import and generate stubs
Feed the Metadata WSDL to your code generator, such as wsimport for Java or a service reference in .NET, to produce typed stub classes for the deploy, retrieve, list, and describe operations.
- Authenticate, then call
Call login through the companion WSDL, capture the returned session ID, and pass it in the SOAP header of each Metadata API request your stubs send.
Describes the Metadata API operations. Required to generate the stub code that performs deploy and retrieve.
Provides the login operation and session ID. Enterprise is typed to one org; Partner is generic and works across orgs.
Set by the WSDL you download. Keep it aligned with your manifest and login WSDL so newer metadata types resolve.
The tool that turns the WSDL into stubs, for example Force.com WSC or wsimport for Java, or a service reference for .NET.
- Generating the WSDL and running deployments require strong access, usually Modify All Data or Modify Metadata; a minimal integration user can hit permission errors.
- Stubs are locked to the WSDL's API version. New metadata types from later releases stay invisible until you download a fresh WSDL and regenerate.
- The Metadata WSDL does not handle login. Skipping the companion Enterprise or Partner WSDL leaves you with no session ID and every call fails.
- For most routine deployments the Salesforce CLI is faster and safer than a hand-built SOAP client, so reach for the WSDL only when you truly need a custom integration.