How to programmatically get Salesforce WSDL files (via REST API)

Last Updated on November 24, 2024 by “Talha Saqib”

Salesforce provides a robust suite of tools for integrating external systems, and a critical component for building these integrations is the WSDL file.

Ever found yourself downloading WSDL files manually from Salesforce every time your schema changes? What if I told you there’s a way to automate this and save valuable time? Whether you’re setting up SOAP integrations or automating workflows in dynamic environments, knowing how to programmatically retrieve WSDL files can be a game-changer.

In this article, we’ll explore the steps to fetch Salesforce WSDL files programmatically and troubleshoot common issues that might arise.

What is a WSDL file?

A WSDL (Web Services Description Language) file is an XML document that describes the functionalities of a web service. It acts as a blueprint for consuming SOAP APIs by detailing the methods, data types, and request-response structure.

When working with Salesforce SOAP APIs, WSDL files provide the contract that client applications must adhere to. This allows developers to generate classes or libraries in various programming languages to consume Salesforce’s services effectively.

WSDL Types in Salesforce

Salesforce provides several types of WSDL files, each serving a specific purpose:

1. Enterprise WSDL
   This is tied to a specific Salesforce organization. It reflects the customizations and metadata specific to your Salesforce instance, making it ideal for scenarios where the Salesforce schema changes frequently.
   
2. Partner WSDL
   The Partner WSDL is more generic and schema-independent. It uses a dynamic model that can work with multiple Salesforce orgs, making it suitable for integrations across different instances.
   
3. Metadata WSDL
   This is used for Salesforce metadata operations, such as retrieving or deploying metadata.
   
4. Tooling WSDL
   Ideal for working with development-related entities, such as Apex classes and triggers.
   
5. Apex WSDL
   This is generated for a specific Apex class that is exposed as a web service. It allows external systems to call your Apex methods.
   
6. Delegated Authentication WSDL
   The Delegated Authentication WSDL is used when Salesforce delegates user authentication to an external system, such as an SSO (Single Sign-On) provider or custom authentication mechanism. This WSDL facilitates secure integration between Salesforce and the external service, allowing users to log in through a centralized authentication system.

Each type has its specific use case, but all can be downloaded manually from Salesforce Setup.

Problem

How can we programmatically obtain Salesforce WSDL files for automation and dynamic integrations?

Solution

While the standard way to retrieve WSDL files is through Salesforce Setup, programmatically fetching them offers far greater efficiency and scalability, especially for dynamic or automated workflows. Before diving into the programmatic solution, let’s briefly discuss the manual method for context.

Get WSDL Manually

1. Log in to Salesforce.
2. Navigate to Setup.
3. Search for API in the Quick Find box.
4. Click on API under Integrations.
5. Select the desired WSDL type (e.g., Enterprise, Partner) and download the file.

This method works well for one-off or less frequent downloads. However, in scenarios where you need to automate the process or fetch WSDLs dynamically, the manual approach falls short.

Get WSDL Programmatically

To fetch WSDL files programmatically, follow these steps:

Step 1: Authenticate with Salesforce

Salesforce requires an access token (Session ID) for authenticated API calls.

Important: Make sure that you obtain session id using the SOAP API login method. The tokens obtained from OAuth REST APIs won’t work.

• Request Type: POST
  
• Target URL:

{{url}}{{site}}/services/Soap/u/{{version}}

• Request Body:

<?xml version="1.0" encoding="utf-8" ?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <n1:login xmlns:n1="urn:partner.soap.sforce.com">
      <n1:username><![CDATA[{{username}}]]></n1:username>
      <n1:password><![CDATA[{{password}}{{secretToken}}]]></n1:password>
    </n1:login>
  </env:Body>
</env:Envelope>

• Response: The resposne will include the <sessionId> tag. You will use that ID in the next step.

Step 2: Use the Session ID to Access WSDL

Once you have the sessionId, you can make a GET request to fetch the desired WSDL file:

• Request Type: GET
  
• Target URLs
  
  • Enterprise: {{url}}/soap/wsdl.jsp?type=*
  • Partner: {{url}}/soap/wsdl.jsp
  • Apex: {{url}}/services/wsdl/apex
  • Tooling: {{url}}/services/wsdl/tooling
  • Metadata: {{url}}/services/wsdl/metadata
  • Authentication: {{url}}/soap/AuthenticationService.jsp

Important: Make sure that the {{url}} is your actual salesforce domain name and not test.salesforce.com or login.salesforce.com

• Header: Add the following header in the request.

Cookie

sid={{sessionId}}

Step 3: Parse and Save the Response

The response will contain the WSDL XML that you can use to implement SOAP APIs to access the Salesforce org as per your needs.

Troubleshooting Tips

Fetching WSDL files programmatically isn’t always smooth. Here are some common issues and their solutions:

1. Invalid sessionId Error
   • Ensure the sessionId is fresh and hasn’t expired.
   • Make sure to sure SOAP Login to access Session ID.
     
2. 403 Forbidden Response
   • Check if your IP is whitelisted in Salesforce (Setup → Network Access).
   • Ensure the user profile associated with the session ID has API access enabled.
     
3. Unexpected WSDL File Content
   • Verify you are using the correct type parameter in the URL (e.g., enterprise, partner).
   • Make sure to use the acutal Salesforce org domain in URL and not test.salesforce.com or login.salesforce.com.
     
4. Authentication Failure
   • Double-check your SOAP login credentials and ensure your security token is appended to the password if required.
     
5. Firewall or Proxy Issues:
   • If you’re behind a corporate firewall or proxy, ensure the necessary Salesforce domains are accessible.

Final Thoughts

Manually downloading Salesforce WSDL files may suffice for simple use cases, but programmatically retrieving them offers efficiency and scalability for advanced workflows. By leveraging Salesforce’s APIs and a bit of automation, you can save time, reduce human errors, and streamline your integration processes.

Have you automated your Salesforce integration workflows? Let us know how this guide helped you or share your insights in the comments!

Resources

• How to get the Enterprise WSDL using the API?
• Generate or Obtain the Web Service WSDLs for Your Organization