Change to OAuth 2.0 for the Salesforce connector in Jitterbit Studio

Introduction

Salesforce is retiring the SOAP API login() authentication method (username, password, and security token). Any Salesforce connection configured with Basic Auth uses this method, and must be changed to OAuth 2.0 Client Credentials to keep working.

Salesforce is not retiring the SOAP API as a whole. Only the login step changes, from a SOAP-based login() call to an OAuth 2.0 token request, so your existing activities, transformations, and operations keep working as they are.

This guide covers the end-to-end change for a single connection: what to configure in Salesforce, what to change in Studio, and how to validate the result before rolling it out. The same steps apply to the Salesforce Service Cloud and ServiceMax connectors, which share the same authentication flow.

Connections already configured with OAuth 2.0 Client Credentials need no change.

This guide walks through five steps:

1. Confirm your agent version and identify every connection that needs to change.
2. Collect an instance URL, client ID, and client secret from a Salesforce external client app or connected app.
3. Change the connection to OAuth 2.0 Client Credentials and enter the new credentials.
4. Verify the change by deploying and running the operations that use the connection.
5. Roll out the change to production.

What changes and what doesn't

Authentication type is a property of the connection, so a single change covers every activity and script that uses that connection:

Before you begin

Confirm the agent version

OAuth 2.0 Client Credentials requires cloud agents, or a private agent meeting these minimum versions:

Check the agent group for each affected environment.

Identify the connections to change

Build an inventory before you start, so that each change is deliberate rather than reactive. The Management Console Endpoints Usage page is the one place that lists Salesforce endpoints across every project and environment in your organization, so start there:

1. Open the Endpoints Usage page and find the rows for the Salesforce connector and the SalesforceLogin function. This page requires the Admin role permission.

2. Click an endpoint to open the endpoint details drawer, which lists the Environment, Project, and Operation where that endpoint is used.

3. Click Go to endpoint to open the connection in Studio, then check its Authentication type. Connections set to Basic Auth need the change.

4. Repeat for each Salesforce row to build the full list.

Scripts that reference a Salesforce connection through Salesforce functions don't need editing, but include the operations that run them when you validate.

Collect the values you need from Salesforce

OAuth 2.0 Client Credentials authenticates with an instance URL, a client ID, and a client secret, which come from a Salesforce external client app or connected app. For the full procedure, see 2-legged OAuth 2.0 prerequisites.

• Instance URL: Your Salesforce instance URL, which depends on your organization's My Domain setting. With My Domain enabled (the default), it takes the form https://exampleDomain.my.salesforce.com.

• Client ID and client secret: The Consumer Key and Consumer Secret of your Salesforce app.

  Important

  As of Spring 2026, Salesforce restricted the creation of connected apps. Create an external client app unless you already have an existing connected app.

Whichever app type you use, confirm these settings in Salesforce:

• Enable Client Credentials Flow is selected in the app's OAuth settings and in its Client Credentials Flow policies.
• Under OAuth Scopes, Manage user data via APIs (api) is selected, along with any other scopes your integration requires.
• For an external client app, the Callback URL is set to the URL for your organization's region.
• A Salesforce user is assigned as the app's Run As (or execution) user.

Change the connection to OAuth 2.0

Make the change in a non-production environment first, then promote the validated project.

1. Record the connection's existing Server host, Sandbox, and Username values. Keeping these allows you to restore the connection if you need to roll back before validation is complete.

2. Open the Salesforce connection for editing from the design component palette, the project pane's Components tab, or the Global Endpoints page.

3. Change Authentication type from Basic Auth to OAuth 2.0 Client Credentials. The credential fields change to Instance URL, Client ID, and Client secret.

   

4. Enter the Instance URL, Client ID, and Client secret you collected from Salesforce. Each of these fields supports project variables, which lets the same project use different credentials in each environment.

5. Click Test to verify the connection, then click Save.

For a description of every field on this screen, see Configure a Salesforce connection.

Verify the change

A successful connection test confirms only that the credentials are valid. Run the operations to confirm the Run As user's permissions are sufficient.

1. Follow the steps in Deploy and execute an operation to deploy and run the operations that use the updated connection, including any operations that run scripts referencing the connection.

2. In the operation logs, confirm each operation succeeded and check the record counts against a run from before the change. A success with fewer records than expected usually indicates the Run As user lacks read access to some records, objects, or fields.

3. Open an activity that uses the connection and click Refresh to reload the Select Object(s) list from Salesforce. If objects or fields that existed before are now missing, the Run As user lacks access to them in Salesforce.

4. Spot-check written records in Salesforce to confirm field values were populated as expected.

5. (Optional) Confirm nothing still uses SOAP API login(). Salesforce provides a test run that blocks all login() calls to an org and returns the same response as the retirement. In Salesforce Setup, under Release Updates, open the SOAP API login() Retirement update, select View Update, then select Enable Test Run. Select Disable Test Run to restore login().

   Caution

   A test run applies to the whole Salesforce org, so any integration that still uses login() fails while it is enabled. Run it in a sandbox after you have changed every connection that authenticates to that org.

6. (Optional, private agents only) To confirm the exact Salesforce API version a request used, check the agent's tomcat/logs/catalina.out log right after clicking Test on the connection or running an operation. It logs the request URL, for example Service request URL: https://login.salesforce.com/services/Soap/u/64.0, where the number after /u/ is the API version invoked.

Roll out the change

1. Once validated, follow the steps in Project transfer to transfer the project to your production environment.

2. If the production environment uses separate Salesforce app credentials, update the connection there with the values for that app. Using project variables for the client ID and client secret keeps this to a variable value change per environment.

3. Follow the steps in Deploy and execute an operation to deploy the operations that use the updated connection, then confirm the first scheduled or triggered runs complete successfully.

4. Once every environment is validated, retire the Salesforce account previously used for Basic Auth according to your organization's practices.

Need help?

For authentication and configuration errors, see Salesforce connector troubleshooting.

For a coordinated change or assistance planning it, contact Jitterbit support or Jitterbit Professional Services.