Is Salesforce deprecating the SOAP API?

Is Salesforce deprecating the SOAP API? Retiring login vs API

Integrations relying on legacy authentication mechanisms require immediate evaluation. Understanding the scope of upcoming technical transitions prevents unexpected service interruptions. System administrators can safeguard data pipelines and maintain seamless platform connectivity by reviewing modern security protocols.

Understanding the Salesforce SOAP API Changes

Is Salesforce deprecating the SOAP API? The short answer is no, the entire SOAP API protocol itself is not going away. However, the core way your applications authenticate using this service is changing dramatically. Salesforce is officially retiring the legacy SOAP API login() operation, meaning that passing raw usernames, passwords, and security tokens directly through the SOAP endpoint will completely cease to work.

This specific deprecation is an effort to improve platform security and shift toward modern, secure-by-default standards. Integrations that already rely on robust token-based frameworks will continue to interact with the SOAP API smoothly without any disruption after this lifecycle event. But theres one counterintuitive factor that many enterprise integrations completely overlook - Ill explain it in the technical migration strategy section below.

The Retirement Timeline and Affected Versions

The retirement of the SOAP API login() method follows a strict, phased schedule across different environments. For existing systems built using API versions 31.0 through 64.0, the retirement becomes fully effective with the Summer 27 release. Once an instance upgrades to this release, any inbound requests hitting the legacy endpoint will encounter immediate authentication failures.

For newer development contexts, the restriction is already in place. The login() method is entirely unavailable in API versions 65.0 and later, forcing all fresh implementations to adopt alternative frameworks. Furthermore, orgs provisioned from the Winter 26 release onward have this legacy authentication disabled by default, signaling a complete architectural transition away from password-based API entries.

How to Replace Legacy SOAP API Login Authentications

To replace the retiring login() functionality, developers must move external software architectures to permission-controlled OAuth 2.0 architectures. Instead of transmitting credentials over the wire to obtain a session ID, external systems negotiate secure tokens via standardized authorization patterns.

The modern secure framework uses Connected Apps or External Client Apps to manage credentials natively. These tools eliminate the risks of hardcoded passwords while granting granular control over scoping. Implementing this configuration allows the application to retrieve an access token, which is then passed securely within the standard HTTP request headers of the continuing SOAP calls.

Technical Migration Strategy: Moving to OAuth 2.0

Heres the critical factor I mentioned earlier: many teams confuse the retirement of the individual SOAP login() call with general API lifecycles. While the login() call disappears in Summer 27, older platform API versions 31.0 through 40.0 face a complete platform removal later in Summer 28. If you upgrade your auth method but leave your endpoint pointing to version 35.0, your integration will still break down a year later.

A structured approach to safe remediation involves the following steps: 1. Go to Setup and download the Login History log covering at least a 30-day window to identify affected systems. 2. Filter the log data by Login Type to pinpoint applications sending username-password details via older API lines. 3. Build a Connected App or External Client App within your Salesforce platform to define authorization parameters.

4. Configure the OAuth 2.0 Client Credentials Flow or JWT Bearer Flow depending on your middleware requirements. 5. Rewrite the external clients code to request an OAuth access token first, then map that token directly into subsequent SOAP request headers. 6. Update the integrations WSDL endpoint entirely to a supported version above 41.0 to escape the 2028 version retirement.

Authentication Methods Comparison

Transitioning your external software away from legacy patterns requires selecting an appropriate modern framework. Here is how the old method compares to supported alternatives.

SOAP API login() (Retiring)

High risk - password rotations instantly break integrations unless clients are updated manually

Weak - relies on sharing highly sensitive administrative credentials over the network protocol

Passes username, password, and security token directly to a SOAP endpoint to extract a session ID

OAuth 2.0 Client Credentials Flow (Recommended)

Low risk - credentials stay detached from standard users, simplifying overall token rotation

Strong - credentials are restricted to a specific backend integration user with explicit scopes

Exchanges an isolated consumer key and consumer secret for a scoped short-lived access token

OAuth 2.0 JWT Bearer Flow

Moderate risk - requires keeping track of certificate expiration dates to maintain live access

Excellent - digital certificates avoid passwords completely, establishing true server-to-server trust

Uses a local private key to sign a JSON Web Token assertion requesting an access token

Enterprise API Reliability Journey

DevCorp, an enterprise company running a high-volume inventory sync service, discovered their legacy ERP integration depended entirely on a hardcoded SOAP login() call built inside an old API version. The development team initially attempted a quick fix by wrapping the password logic inside an encrypted script, but this did nothing to address the upcoming endpoint retirement.

The turning point arrived during sandbox testing when a release simulator turned off legacy login options completely. The inventory system failed immediately, causing automated product sync failures and blocking critical customer orders.

Realizing a patch would not work, they built an External Client App configuration. They ran into friction when dealing with replication lag on automated access token refreshes, which threw timeout errors. They solved this by writing a retry handler that cached tokens locally for 15-minute windows.

The system stabilized perfectly before production enforcement. Ultimately, API authentication failure alerts dropped to zero, and the team completely removed raw credentials from external config files, ensuring long-term resilience.