Not every critical integration is visible. Some have been running in the background at night for years, use a dedicated Salesforce user, and sign in with username, password, and security token. As long as the data keeps flowing, few people ask what authentication sits behind it.
These are exactly the connections that now need to be reviewed. Salesforce is retiring the SOAP API call login() in API versions 31.0 through 64.0 with Summer ’27. The call is already unavailable in API version 65.0 and higher. Salesforce recommends moving external applications to External Client Apps and OAuth.
The distinction matters: this is not about SOAP disappearing as an interface. It is about one specific authentication method. Applications that sign in via SOAP API login() will no longer be able to authenticate after the change. Every downstream API call therefore depends on this change as well.
Not every old integration is a problem. It becomes one when nobody knows any more how it signs in, who owns it, and which process depends on it.
What Salesforce is actually changing
Salesforce describes the change as the retirement of SOAP API login() for API versions 31.0 through 64.0 with Summer ’27. Until then, the call remains supported in those versions. From Summer ’27, it is no longer available.
In the Summer ’26 Developer Guide, Salesforce calls this out as a particularly relevant item for integration owners. It notes that integrations using username-password authentication over SOAP will fail if they are not migrated in time. As the target, Salesforce names OAuth via External Client Apps, including with JWT-based tokens.
In parallel, Salesforce continues to move the platform toward modern authentication. Summer ’26 also describes a new permission that controls who is allowed to authenticate via SOAP login(). In newly created orgs, this control is enforced more strictly by default.
For existing organisations, this means the question is not only relevant in 2027. It already affects the inventory, the prioritisation, and the technical planning today.
Why this is more than a version update
At first glance, the change might look like an ordinary API version topic. An old version reaches end of life, so the integration is lifted to a new version. With SOAP login(), that logic falls short.
The affected call is not just some business operation. It sits at the very start of the connection. If authentication fails, the integration never even reaches the actual data or process calls.
A nightly synchronisation can be cleanly built, have well-documented field mappings, and still fail if it still authenticates via login(). The same applies to an external reporting tool, an old middleware job, or a small in-house build that has reliably fetched data for years.
The migration should therefore not be treated as a pure code change. It is a question of inventory: which connections exist at all, who owns them, how critical are they, and how do they sign in today?
With
SOAP login(), it is not a single data call that disappears. It affects the entry point of the connection. If authentication fails, the integration no longer reaches the actual process at all.
What can be affected
Not every Salesforce integration is automatically affected. What matters is whether an application uses SOAP API login() in the affected API versions for authentication.
| Area | Possible examples | Typical risk |
|---|---|---|
| In-house builds | Scripts, batch jobs, internal tools, old Java or .NET applications | The original developer is gone; credentials have grown historically |
| External tools | Reporting, ETL, data exports, connectors | Authentication is hidden in the UI or only shown as "Salesforce login" |
| Middleware and integration platforms | Older flows, legacy connectors, individually configured adapters | The connection runs stably but has not been reassessed in years |
| Packages and partner solutions | Installed applications with their own Salesforce connection | Dependency on the vendor and their migration path |
| Ad-hoc automations | Small helper jobs for data sync, monitoring, or support | No clear owner, no operational documentation |
Integrations that are rarely changed are especially critical. Precisely because they run reliably, they often do not surface in modernisation projects.
The inventory is the first project step
Salesforce points out that affected applications can be identified through API usage data. The help article names the API Total Usage EventLogFile for finding applications that authenticate via SOAP API login().
A useful inventory should combine technical and business information:
- Which users and applications still authenticate via
SOAP login()? - Which API versions and endpoints are being used?
- Which business processes depend on the connection?
- Who is the business and technical owner?
- Are there vendors, packages, or source code that need to be adapted?
This list matters more than the sheer number of connections. A single integration can carry a critical process, while ten others only serve historical exports.
The second look belongs to the credentials. Username-password logins are often tied to technical users, shared credentials, or secrets that have not been rotated in a long time. The migration is therefore also an opportunity to set up ownership, permissions, and secret handling more cleanly.
OAuth is not just a different login
The recommended direction is clear: External Client Apps and OAuth. The integration is then no longer established through a direct SOAP login with username and password, but through a controlled OAuth flow.
Server-to-server integrations usually need a flow that works without interactive user sign-in. In the Developer Guide, Salesforce names OAuth with External Client Apps and JWT tokens as a migration path, among others. In addition, in Summer ’26 the SOAP API accepts JWT-based access tokens from Salesforce OAuth flows in the sessionId header. This allows SOAP-based calls to remain in use without employing SOAP login() as the authentication step.
Choosing the right OAuth flow is essential here. Simply moving from SOAP login() to another username-password mechanism does not solve the problem properly. Salesforce has also announced a retirement of the OAuth 2.0 username-password flow for Connected Apps for Winter ’27.
The technical target architecture should therefore not be: the old password login somewhere else. It should be: a clearly defined client app, limited permissions, traceable tokens, and a clean lifecycle for credentials.
The migration should not move old password patterns to a new place. What matters is an authentication standard with clear permissions, a token lifecycle, and accountability.
Not every integration has to be rebuilt
A migration does not automatically mean that business integration logic has to be replaced. In many cases the actual data flow stays the same: the same objects, the same fields, the same target application. What changes first is how the application authenticates against Salesforce.
Even so, the opportunity should not be scoped too narrowly. For old connections, at least a brief architecture check is worthwhile. Does the integration use overly broad permissions? Does it use a general admin user? Is it clearly documented which data is read or written? Is there error handling, monitoring, and an owner?
Otherwise, a pure authentication swap can quickly turn into a superficial repair. The connection works again afterwards, but the structural weaknesses remain.
In the Salesforce landscape in particular, such integrations have often grown over years. An export was added, a field came along, a tool was swapped, a user stayed in place. The SOAP login change is a good occasion to make this grown integration reality visible.
Test runs before the deadline
For the release update, Salesforce also describes a test run in which SOAP API login() is disabled in the org. This makes it possible to check which connections would fail before the change takes effect for good.
Such a test is only helpful if it is clear beforehand which systems need to be observed. Otherwise something does fail, but the attribution remains unclear.
A step-by-step approach makes sense:
-
Inventory Capture all known Salesforce connections, review API usage, and map technical users.
-
Prioritise Handle critical business processes, external vendors, and hard-to-maintain in-house builds first.
-
Migrate and test Move authentication to OAuth and External Client Apps, limit permissions, and test failure cases in a sandbox or controlled test windows.
-
Monitor After the change, deliberately watch API usage, login events, error messages, and job results.
The test run should not be understood as a one-off checkbox in the release update menu. It is part of a migration project that has to bring technical dependencies and business criticality together.
What companies should clarify now
There is still time until Summer ’27. For production Salesforce landscapes, that is nevertheless no reason to postpone the review. The effort usually lies not in the code, but in finding and assessing old connections.
Before the migration, three decisions should be settled:
-
Which integrations are actually affected? Not every use of SOAP is automatically a problem. What matters is authentication via
SOAP API login()in the affected API versions. -
Which application is critical for which process? A technical connection has to be tied to its business process. Only then can you decide which migration comes first.
-
How should authentication be standardised going forward? External Client Apps, OAuth flows, technical users, permissions, and secret handling should not be improvised per integration.
These decisions prevent each team from migrating on its own and ending up with different security and operating models.
Old logins are often a symptom
The retirement of SOAP API login() is not merely a Salesforce release topic. It makes visible how much companies still depend on authentication patterns that have grown historically.
An integration can be important to the business and technically old. It can run stably and still pose a risk. It can move data for years without it being clear who owns it or how it would be restored in a failure.
That is exactly why the migration should not start shortly before Summer ’27. Reviewing early does not only surface affected SOAP logins. It also gives a better view of your own integration landscape.
The goal is not to replace SOAP across the board. The goal is to retire old authentication patterns in a controlled way and to set up Salesforce integrations so that they remain traceable, maintainable, and secure through the coming release cycles.