Salesforce SOAP API login() Retirement: What Leaders Need to Know Before Summer ‘27
Salesforce is retiring SOAP API login() authentication in Summer ‘27. Any integration that still signs in to Salesforce this way will stop working unless it moves to supported OAuth-based authentication, such as External Client Apps. The hard part for most organizations isn’t the fix. It’s knowing which integrations are affected.
Most organizations using Salesforce have integrations. Your website may send leads into Salesforce. Your accounting system may exchange customer information. A fundraising platform, data warehouse, middleware tool, custom application, or something a consultant built years ago may be connected behind the scenes.
Many organizations don’t have a complete inventory of those connections, or know how each one authenticates.
For executives, this is not really an API problem. It is a business continuity problem.
Key takeaways
- SOAP API login() is retired in Summer ‘27. Integrations that use it must move to OAuth-based authentication.
- Salesforce API versions 31.0–40.0 become unsupported in Summer ‘27 and are retired in Summer ‘28.
- The biggest risk is usually older, undocumented integrations that nobody actively owns.
- Start with an inventory, then confirm it against Salesforce Login History and API Total Usage logs.
What is Salesforce retiring in Summer ‘27?
SOAP is one of the technologies applications use to communicate with Salesforce. Historically, some integrations used a SOAP function called login(). It sends a Salesforce username and password and receives a session that lets the application work with Salesforce.
Salesforce is retiring that authentication method in Summer ‘27. It is directing affected integrations to supported OAuth-based authentication, including External Client Apps.
In plain terms: OAuth is a more secure way for one system to get permission to access another without passing a stored username and password. External Client Apps are Salesforce’s current recommended way to set up that permission for an integration.
Other Salesforce API deadlines to know
The login() retirement isn’t the only change on the calendar.
| When | What changes | What it means |
|---|---|---|
| Spring ‘26 | Creation of traditional Connected Apps restricted | New integrations should use External Client Apps |
| Summer ‘27 | SOAP API login() retired | Integrations using it must switch to OAuth |
| Summer ‘27 | API versions 31.0–40.0 deprecated and unsupported | Integrations on these versions should be upgraded |
| Summer ‘28 | API versions 31.0–40.0 retired | Calls using these versions will fail |
Individually, these might sound like technical housekeeping. Taken together, they raise a more important question:
Do we actually know what is connected to our Salesforce system?
Why forgotten Salesforce integrations are the biggest risk
New integrations usually aren’t the biggest concern. Someone knows who built them, why they exist, and how they work.
Older integrations can be different.
Perhaps a former employee built a nightly synchronization years ago. Maybe a vendor configured something during the original Salesforce implementation. Perhaps an old service is running on a server that nobody wants to touch because, well, it still works.
Until it doesn’t.
An aging integration may be performing an important business function while receiving almost no attention. It could be creating leads, updating financial information, moving donations, synchronizing customer records, or feeding management reports.
The Summer ‘27 changes provide a deadline. They also expose a broader governance problem: an organization cannot maintain an integration it doesn’t know it has.
How to find integrations affected by the SOAP login() retirement
You don’t need to begin with a major technical project. Start with an inventory.
Step 1: Build a business inventory
Ask your Salesforce administrator, IT team, vendors, and consultants which systems exchange information with Salesforce. For each integration, record:
- its business purpose
- its owner
- the vendor or developer
- its authentication method
- its API version
- what would happen if it stopped working
Step 2: Check Salesforce Login History
For the SOAP login() retirement, Salesforce recommends reviewing Login History. You can identify SOAP API logins using fields such as Login Type, Login Subtype, and API Type. The username tied to each login is often a clue to which system is responsible.
Step 3: Review API Total Usage event logs
API Total Usage event logs can show the API family, API version, user, client name, and connected application behind API activity. Salesforce recommends these logs for identifying applications on older API versions.
API-enabled orgs can access recent API Total Usage data. Orgs with Event Monitoring may have longer retention.
A caution: a short sample is not proof that you’ve found every integration. Something that runs monthly, quarterly, or only when a specific event occurs may not appear in a brief review window. That’s why the technical review and the business inventory need to happen together.
Questions to ask about every Salesforce integration
Don’t just ask, “Will it break?” Ask these:
- What business process depends on it? If it fails, does someone notice right away, or could bad or missing data pile up quietly?
- Who owns it? Someone should be responsible for the business process, and someone should be able to maintain the technology.
- How does it authenticate? SOAP login(), OAuth, a Connected App, an External Client App, or something else?
- Which Salesforce API version does it use? Older versions deserve extra scrutiny, even if login() doesn’t affect them.
- Is the vendor still supporting it? A supported product may just need an upgrade. Abandoned custom code may take considerably more work.
- How would you know if it failed? “A customer will eventually call us” is technically an alerting strategy, but not a particularly good one.
Summer ‘27 is the deadline, not the project start date
Don’t wait until the retirement date to investigate.
Finding an affected integration is only the first step. Someone may need to:
- locate the source code
- contact a vendor
- figure out who owns an old server
- update authentication and create an External Client App
- test in a sandbox
- verify that the business process still works
Some integrations will be straightforward. For others, figuring out what the integration actually does may take longer than fixing it.
Use the deadline to build better integration governance
The SOAP login() retirement is one specific Salesforce platform change. There will be others.
The more valuable exercise is creating a repeatable way to answer this question: What systems depend on Salesforce, who owns them, and are they still using supported technology?
That’s the kind of ongoing oversight a Salesforce managed services partner provides. It also fits naturally into broader business process improvement work.
Frequently asked questions
When is Salesforce retiring SOAP API login()?
Salesforce is retiring SOAP API login() authentication in Summer ‘27. Integrations that still use it will need to move to supported OAuth-based authentication, such as External Client Apps, before then.
What happens if an integration still uses SOAP login() after Summer ‘27?
It will no longer be able to authenticate to Salesforce, so whatever business process it supports will stop working. That could be lead capture, data syncs, financial updates, or reporting.
How do I find out which integrations use SOAP login()?
Review Salesforce Login History and filter by Login Type, Login Subtype, and API Type. Pair that with a business inventory from your admin, IT team, and vendors, because some integrations run too rarely to show up in a short log review.
Which Salesforce API versions are being retired?
API versions 31.0 through 40.0 become deprecated and unsupported in Summer ‘27 and are retired in Summer ‘28. After retirement, calls using those versions will fail.
What is an External Client App in Salesforce?
It is Salesforce’s recommended way to configure how an outside application connects to Salesforce using OAuth. Since Spring ‘26, Salesforce has restricted creation of traditional Connected Apps and recommends External Client Apps for new development.
Get help reviewing your Salesforce integrations
Better Partners helps organizations review their Salesforce integration landscape, investigate API activity, identify potentially affected integrations, and build a practical remediation plan.
If you’re unsure what’s connecting to your Salesforce org, or whether an older integration could be affected, contact Better Partners to start the conversation.
