Salesforce SOAP API Retirement: What Changes, What Breaks, and How to Prepare Before Summer ’27

Introduction

If your Salesforce integrations still authenticate by passing a username, password, and security token through the SOAP API login() call, you are working against a deadline that Salesforce has made non-negotiable. The SOAP API login() operation for API versions 31.0 through 64.0 is set to retire with the Summer ’27 release. Once that enforcement goes live, every integration relying on this authentication method will stop working. API calls will fail, data syncs will break, and automated business processes will halt with no grace period.

This is not a theoretical risk. Salesforce has already retired API versions 7.0 through 20.0 in Summer ’22 and versions 21.0 through 30.0 in Summer ’25. Organizations that did not upgrade before those deadlines saw their integrations fail outright. The SOAP login() retirement follows the same trajectory, and the window to act is narrowing. For enterprises running 10 or more integrations, a full migration typically requires four to eight weeks of planning, testing, and staged rollouts.

What Exactly Is Being Retired?

A common misconception is that Salesforce is retiring the SOAP API entirely. That is not accurate. The SOAP API itself, including data operations such as query, create, update, and delete, will continue to function after Summer ’27. What Salesforce is retiring is the SOAP API login() authentication operation: the mechanism that allows external applications to authenticate by sending a username-password combination to obtain a session ID.

This distinction matters because it determines what you need to fix. If your integrations already authenticate through OAuth 2.0 flows (JWT Bearer, Client Credentials, Authorization Code, or Named Credentials), they are already compliant. The retirement specifically targets integrations that call the SOAP Enterprise WSDL (/services/Soap/c/<v>/) or SOAP Partner WSDL (/services/Soap/u/<v>/) login endpoints using username-password authentication in API versions 31.0 through 64.0.

The Salesforce SOAP API Retirement Timeline at a Glance

Salesforce has been phasing out legacy API versions and authentication methods progressively over the past four years. Understanding where Summer ’27 fits into this sequence helps clarify the urgency.

As the table shows, this is not a sudden change. Salesforce has followed a structured deprecation path, giving organizations advance notice at every stage. The Summer ’27 retirement is the final phase, and it eliminates SOAP login() across all remaining supported API versions.

Why Is Salesforce Forcing This Change?

The retirement is driven by three factors that directly affect enterprise security posture.

1. Credential-based attacks remain the primary threat vector. The Verizon Data Breach Investigations Report found that 67% of data breaches involve compromised credentials. SOAP login() authenticates by transmitting usernames and passwords over the wire, making it an inherently riskier method than token-based alternatives.
2. SOAP login() bypasses multi-factor authentication (MFA). Salesforce enforced MFA across all user logins starting in February 2022, but SOAP login() operates outside that enforcement boundary. Every integration still using SOAP login() is effectively a backdoor that bypasses your MFA investment.
3. Modern authentication standards offer superior control. OAuth 2.0 provides short-lived access tokens, scoped permissions, revocable access, and complete token lifecycle auditing. These capabilities are foundational to zero-trust security models, and Salesforce is aligning its platform accordingly.

Who Is Affected?

The impact extends well beyond custom-built integrations. Any application, connector, or tool that authenticates to Salesforce using username-password through the SOAP API is in scope. This includes middleware platforms such as MuleSoft, Workato, Boomi, and Informatica, where legacy connection configurations may still reference SOAP login(). It includes ETL tools and data loaders, particularly older versions of Salesforce Data Loader that pre-date OAuth support. Custom integrations built before 2015, third-party AppExchange packages with hardcoded authentication, and automated test frameworks that authenticate via SOAP endpoints are all potentially affected.

Even Salesforce-native features are not immune. Outbound Messaging workflows that return SOAP calls using the EnterpriseURL or PartnerURL from the message payload, Data Loader configurations, and legacy Connected App implementations are all areas that Salesforce has flagged for review.

How to Identify Affected Integrations in Your Org

The most critical step is building a complete inventory of where SOAP login() is used. Salesforce provides two primary methods to surface this.

Login History: Navigate to Setup, then Login History. Filter for entries where the API Type is “SOAP Enterprise” or “SOAP Partner,” and the Application field shows “N/A”. The N/A value indicates the client is not bound to a Connected App or External Client App, which is the exact pattern targeted by this retirement. Contact the user listed in the Username field to identify the application.

API Total Usage EventLogFile: This event type consolidates request information across SOAP, REST, Bulk, ApexREST, and ApexSOAP APIs. Look for entries with an empty CONNECTED_APP_ID field, which indicates the application used either SOAP login() or a session-based authentication method. All orgs have access to the past 24 hours of this log. With Event Monitoring enabled, retention extends to 30 days.

Salesforce also provides a Release Update tool that lets you test the retirement enforcement in a sandbox environment. Navigate to Setup, then Release Updates, locate the “SOAP API login() Retirement” update, and enable a test run. This lets you observe which integrations break without affecting production.

The Migration Path: OAuth 2.0 and External Client Apps

Salesforce recommends migrating all affected integrations to OAuth 2.0 authentication through External Client Apps. The choice of OAuth flow depends on your integration pattern.

• JWT Bearer Token Flow is the recommended option for server-to-server integrations. It uses a digital certificate to sign a JSON Web Token, eliminating the need to store or transmit client secrets. The JWT is posted to the Salesforce OAuth token endpoint, and upon verification, Salesforce issues a short-lived access token. This flow requires no user interaction and is well suited for ETL tools, middleware connectors, and automated backend processes.
• Client Credentials Flow is a simpler server-to-server alternative for environments where certificate management is not feasible. It exchanges a client ID and client secret for an access token. While less secure than JWT Bearer (the secret is transmitted with each request), it is still significantly safer than username-password authentication and supports scoped permissions.
• Authorization Code Flow (with PKCE) is the standard choice for browser-based or user-driven integrations where the application acts on behalf of a logged-in user. The user authenticates via the Salesforce login page, and the application receives an authorization code, which it exchanges for tokens.
• Named Credentials provide a Salesforce-native abstraction layer for centrally managing authentication. They allow admins to configure OAuth settings declaratively, reducing the need for hardcoded credentials in Apex code or integration configurations. For organizations managing multiple integrations, Named Credentials significantly simplify credential rotation and access auditing.

Practical Migration Advice

For a single integration, migration typically takes one to three days, including testing. Organizations with 10 to 20 integrations across multiple middleware platforms should budget four to eight weeks for a complete migration that includes regression testing and staged rollouts across sandbox, staging, and production environments.

A common pitfall is completing the migration in production and forgetting to update the sandbox and staging environments. Build a complete environment checklist before you begin. Another frequent oversight is third-party vendor dependencies. If a component or application is from a vendor, contact them to confirm they support OAuth-based authentication and request an updated version if they do not.

Start with your sandbox environment, validate every migrated integration end-to-end, and only then proceed to production. The Release Update test run feature is your safety net. Use it.