Skip to Content

Change the WSDL version


This page describes how to change the WSDL version used by an existing NetSuite connection.

Periodically upgrading the WSDL version used by your NetSuite connection in order to always be using a fully supported version is a recommended good practice. The steps below outline the best way to make the change, ensuring a seamless upgrade.

Obtain a supported and NetSuite account-specific URL

Make sure to use a fully supported version of the NetSuite WSDL. Jitterbit supports the WSDL versions listed in NetSuite prerequisites.

The WSDL URL must be provided in the format of an account-specific WSDL URL. Instructions for obtaining the WSDL URL are provided in Use a NetSuite account-specific WSDL URL.

Change the WSDL version

Once you have obtained an account-specific URL that uses a fully supported WSDL version, follow these steps:

  1. As a precaution, before making any changes, deploy the project so you have a restore point in case you need to revert changes. Another recommended best practice is to make the following changes in a non-production environment first, then migrate the project to a production environment.

  2. Duplicate your existing NetSuite connection. Then edit it to change the WSDL Download URL, replacing it with the new URL you've obtained. See also the NetSuite docs for additional information on upgrading.

  3. Go through your operations to replace each existing NetSuite activity with a new one created from the new connection. As you replace each activity, you must refresh the schemas in adjacent transformations to use the schemas associated with the new activities. As each transformation's schemas are refreshed, you must recreate any mappings.


Even though it is possible to simply replace the WSDL URL of an existing connection and reconfigure the existing activities, then refresh each transformation and recreate the mappings, we discourage this practice. In such a scenario, no validity errors are reported and it is possible to deploy the project, inadvertently overwriting successful operations with ones that fail at runtime due to the WSDL mismatches within schemas.