SOAP API login() retirement in versions 31.0–64.0 (Summer '27) — how to inventory and migrate integrations to OAuth

This article explains how to inventory integrations still authenticating with the deprecated SOAP API login() call in API versions 31.0 through 64.0, and how to migrate those integrations to OAuth 2.0 before the mandatory Summer '27 retirement. This is a release advisory, not a defect, so action is required only if an integration actually authenticates this way in the affected version range.

Why This Change Is Happening

Salesforce is retiring the SOAP API login() call in API versions 31.0 through 64.0 as part of the Summer '27 release. Integrations that authenticate using SOAP login() in that version range must move to OAuth 2.0 authentication using External Client Apps before the cutover, or those integrations will stop authenticating.

Prerequisites

• Salesforce admin access
• Login History access (Setup > Login History)
• Development or admin access to the affected integration applications

Step 1: Identify Affected Integrations Using Login History

1. Go to Setup > Login History.
2. Filter by Login Type = API and API Version in the range 31.0–64.0.
3. Review the Username, Application, and Source IP columns to identify which integration users and applications are making SOAP login() calls.
4. Download the Login History report for a representative time window (for example, the past 30 days) to share with integration owners or developers.

Step 2: Determine the OAuth Migration Path

For unattended server-to-server integrations with no human user in the loop, choose one of the following OAuth 2.0 flows:

• OAuth 2.0 Client Credentials Flow – the simplest SOAP login() replacement. The integration authenticates with a consumer key and secret tied to a "run-as" user. Recommended for most custom code and ETL (Extract, Transform, Load) integrations.
• OAuth 2.0 JWT Bearer Flow – uses a signed certificate instead of a client secret. More secure for sensitive integrations since there is no secret to rotate.

Both flows return an OAuth access token that replaces the SOAP session ID in subsequent API calls. The underlying SOAP calls themselves do not need to change – only the authentication step changes.

Step 3: Create an External Client App

1. Go to Setup > External Client Apps and create a new app.
2. Select OAuth Settings and configure the appropriate OAuth flow.
3. Assign the app to the integration user.
4. Update the integration client to use the OAuth token endpoint and token exchange instead of SOAP login().

Step 4: Validate and Cut Over Before Summer '27

Summer '26 introduces an optional "Use API Auth" user permission that lets admins opt into the new behavior early for controlled testing. Use this permission to validate migrated integrations before the mandatory cutover in Summer '27.