I am trying to understand more deeply that why can't we do all the integration using Partner WSDL , why does salesforce even have a Enterprise WSDL when partner wsdl can provide the same functionality. I did my research and read through some of the articles:


Much better explanation here:

Enterprise WSDL - This WSDL document is for customers who want to build an integration with their Salesforce organization only.It is strongly typed, which means that it contains objects and fields with specific data types, such as int and string. Customers who use the enterprise WSDL document must download and re-consume it whenever their organization makes a change to its custom objects or fields or whenever they want to use a different version of the API.

Partner WSDL - This WSDL document is for customers, partners, and ISVs who want to build an integration that can work across multiple Salesforce organizations, regardless of their custom objects or fields. It is loosely typed, which means that you work with name-value pairs of field names and values instead of specific data types. The partner WSDL document only needs to be downloaded and consumed once per version of the API

On reading above links and contents I see that the only difference is enterprise is strongly typed and partner is loosely typed. My questions are:

  1. First off all document says Customer and Partner. What is the difference? Both are external parties trying to access salesforce from outside system.
  2. What advantage does it gives to use a strong typed WSDL. Why would an external system would even think of using enterprise wsdl. What are the scenarios in which enterprise is really helpful over partner. Any examples? ( I know that you use enterprise wsdl if you want to built integration with a specific org, but this does not say why you want choose enterprise wsdl over partner to built integration with a specific org)

Looking for more practical answers(scenarios or examples) instead of more theoretical.

1 Answer 1


A critical difference between the two is how change is handled i.e. what needs to be done when the org the WSDLs are generated from's structure changes - when new fields and objects being added. In most businesses such changes do happen.

With the Partner WSDL, the client code can automatically adapt with no need for the Partner WSDL to be generated again and then run through client code generation tools. The client can also be used with different orgs because of this adaptability. The client code is harder to write but the solution typically requires less maintenance over time.

With the Enterprise WSDL, field names and types and object names are hard wired into the generated WSDL and therefore into the generated client code. While this makes the client code easier to write, it also means the Enterprise WSDL and client code generation need to be redone when change happens. So good for working with a single org where nothing changes, or where new attributes are optional (so can be left out).

  • 1
    Thanks! Why is it easier to write the client code with enterprise wsdl? Is it because they can use the field api name directly instead of using Sobject describe and get the field names?
    – SfdcBat
    Commented Jun 23, 2017 at 7:33
  • 1
    @SfdcBat Yes with the Enterprise WSDL you hard code references to fields and manipulate them via getter and setter methods. With the Partner WSDL you discover the field names and have to loop over them calling map-like get and set methods casting to the assumed types where necessary (or writing logic that supports multiple types which is even harder). You also have to do the extra thinking of what the code should do as new fields are added over time.
    – Keith C
    Commented Jun 23, 2017 at 7:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .