Salesforce SOAP API login() retirement: find affected integrations now

Salesforce has confirmed that the login() operation in SOAP API versions 31.0 through 64.0 will no longer be supported or available with the Summer ’27 release. Salesforce’s active-retirements schedule lists this as June 2027. Any code, package, application or integration that still uses that operation to authenticate to a Salesforce org will fail to establish a session after retirement, and its subsequent API calls will fail.

This needs attention, but it does not mean that every SOAP integration must be rebuilt or that SOAP API itself is disappearing. The confirmed change concerns the username-and-password authentication step provided by login(). Salesforce’s Summer ’26 developer guidance says SOAP API can accept access tokens obtained through Salesforce OAuth flows in the sessionId header. The practical task is therefore to find the affected authentication paths, understand who owns them and migrate each one safely.

The exact upgrade date depends on the Salesforce instance. Treat June 2027 as the confirmed retirement month, check the maintenance calendar for the org’s release schedule and plan backwards with margin.

What Salesforce has confirmed

Salesforce currently supports SOAP API login() in API versions 31.0–64.0. It is not available in API version 65.0 and later, and versions 30.0 and earlier have already been retired. With Summer ’27, support for login() in the remaining versions ends.

Salesforce says the change affects any custom code, package, application or integration that uses login() to authenticate. Its recommended direction is to use External Client Apps and OAuth, with client credentials or JWT bearer flows for appropriate server-to-server cases. Where an application comes from a third-party supplier, Salesforce advises contacting the developer for a supported update.

New orgs already provide an early warning of the direction of travel: SOAP API login() is disabled by default. Summer ’26 also added an administrative control for its use in newly created orgs. These controls are useful context, but enabling a legacy method is not a migration plan for an existing production dependency.

Do not confuse three different authentication patterns

A reliable inventory needs more than a search for the word “SOAP”. Teams often use “username and password integration” to describe several technically different arrangements.

• SOAP API login(): the application calls the SOAP login operation and receives a session ID. This is the method covered by the Summer ’27 retirement.
• OAuth username-password flow: the application sends a Salesforce username and password to an OAuth token endpoint. Salesforce has a separate release update for retiring this flow, now scheduled for 20 February 2027.
• OAuth client credentials or JWT bearer: the application uses an external client app and a purpose-designed machine authentication flow. These are potential destinations, not proof that an integration is already safe.

The distinction matters because the evidence, owner and remediation can differ. A single integration user may be used by several services, some using login() and others using OAuth. Conversely, an old middleware component may authenticate once through SOAP and then issue many REST or Bulk API calls. Classify the authentication handshake, not simply the downstream API traffic.

Build an evidence-based inventory

Salesforce’s new July 2026 migration guidance identifies Login History as the primary place to look. In Setup, review API logins for versions 31.0–64.0 and use the username, application and source IP to help identify the calling component. Download a representative period so findings can be reconciled with integration owners.

Salesforce also points to the API Total Usage event in EventLogFile as supporting evidence. It can help connect API activity to versions and clients, but logs rarely provide a complete business inventory by themselves. Scheduled monthly jobs, quarter-end processing, disaster-recovery tooling and rarely used data fixes may not appear in a short sample.

Combine technical evidence with four other sources: the integration catalogue; middleware and ETL schedules; secrets or service-account registers; and supplier application inventories. Ask operations and finance teams about spreadsheet add-ins, desktop tools and periodic data loads that may sit outside the formal architecture.

For each candidate, record the business purpose, environment, integration user, owner, supplier or code repository, authentication method, API version, execution frequency, data sensitivity, last confirmed successful run and recovery route. Mark uncertainty explicitly. “No activity seen in 30 days” is not the same as “retired”.

Choose the target flow from the use case

Salesforce recommends OAuth client credentials or JWT bearer for server-to-server scenarios, but the choice should follow a small security and operating assessment.

Client credentials can suit an unattended service. Salesforce requires an external client app and a nominated integration user. The app exchanges its consumer key and secret for an access token; the flow does not issue refresh tokens. The secret must be stored and rotated securely, and whoever can use it can obtain a token acting as the configured integration user.

JWT bearer uses a signed assertion and certificate rather than a shared client secret. It can be appropriate where the team has sound certificate lifecycle management. It is not automatically safer if certificate ownership, private-key storage and expiry monitoring are weak.

Interactive web-server flows with PKCE are more appropriate where a person is genuinely present and must authorise access. Do not force a machine-to-machine integration through a human login merely because it is familiar.

In every case, review the integration user’s profile, permission sets and OAuth scopes. Moving to OAuth should not preserve excessive access by accident. Use a dedicated integration identity where practical, grant only the data and operations required, and document who can change the external client app’s settings and policies.

Test the authentication change without hiding application risk

Start in a representative non-production environment. Prove the complete token exchange, not only that a token is returned. Run realistic reads, writes, error cases, bulk operations and long-running schedules. Confirm how the client obtains a new token after expiry and how monitoring distinguishes authentication failure from data or business-rule failure.

If the integration continues to call SOAP operations, test that the OAuth access token is passed correctly in the SOAP sessionId header and that the client no longer invokes login(). Check vendor documentation and supported versions rather than modifying a packaged connector informally.

Plan a controlled cutover with named owners on both the Salesforce and external-system sides. Define success measures, rollback criteria and a short period of heightened monitoring. Avoid leaving the old credential path enabled indefinitely “just in case”; set a date to remove obsolete passwords, secrets, permissions and configuration after the new route is stable.

A practical timetable for platform owners

• Now: assign a retirement owner, export relevant login evidence and create the candidate inventory.
• Next 30–60 days: contact suppliers, classify each authentication pattern and agree the target OAuth flow.
• Before the end of 2026: migrate high-risk or poorly understood integrations in test environments and confirm secret or certificate operations.
• Well before Summer ’27: complete production cutovers, observe normal business cycles and remove the legacy path.

This is Ostrelis operational guidance, not a Salesforce timetable. The right sequencing depends on the number of integrations, supplier lead times and business calendar. Starting early is valuable because ownership and evidence are usually harder than the code change.

The Ostrelis view

Authentication retirements expose an integration-governance problem before they expose a technical one. If nobody can say which system uses an integration user, who can change it or what happens when it fails, selecting an OAuth flow is not yet the main task.

Use this retirement to establish a maintained register, named service owners, least-privilege identities, credential lifecycle controls and observable failure routes. Those controls reduce the risk of future platform changes as well as this specific deadline.

Ostrelis can help organisations investigate Salesforce dependencies, coordinate suppliers, design proportionate authentication changes and test cutovers. See our Salesforce integration services, managed Salesforce support and approach and experience.