Salesforce SOAP Login Retirement: What Higher Education Needs to Do Before June 2027

Salesforce retires the SOAP API login() call in the Summer '27 release, ending username-and-password authentication for integrations. In higher education the affected systems are the middleware, scheduled jobs, and vendor connectors that log in with an integration user — not the student information system itself. This post explains what is changing, where the exposure sits in a typical higher education Salesforce environment, and the steps institutions should take before June 2027.

What is changing in Summer '27

Salesforce announced the SOAP login retirement in its Winter '26 release notes in September 2025, and it received little attention in higher education. The login() call — the method that lets an integration authenticate with a username, password, and security token — will stop working in the Summer '27 release, scheduled for June 2027. The retirement applies to login() in SOAP API versions 31.0 through 64.0. The call is already unavailable in version 65.0 and later.

The SOAP API itself continues to work after Summer '27. What ends is the username-and-password authentication path. Salesforce's instruction is direct: before Summer '27, customers and partners must modify or upgrade their applications to use External Client Apps for authentication.

For years, the simplest way to connect a system to Salesforce was to create an integration user, share its credentials with the external tool, and let that tool call login() to obtain a session. It was easy to set up and reliable, which is exactly why many institutions still run integrations built this way that have gone unreviewed since the day they went live.

Which higher education integrations are affected

When institutions hear "integration," they think of the student information system: Banner, Colleague, Workday Student, or PeopleSoft. The SIS is where most teams look first.

The exposure sits one layer over. Each of those systems exchanges data with Salesforce through a middle layer, and that layer holds the integration user credentials. Common examples include:

• Integration platforms such as Jitterbit, Boomi, Informatica, and MuleSoft
• Data Loader jobs running on a scheduled task
• Custom scripts (Python, PowerShell, or similar) written by central IT and left in place
• CRM-adjacent systems such as Slate, document imaging platforms, texting tools, and dialers

The question to ask of every connected system is "how does it log in?" If the answer involves a password field and a security token, the integration is affected. This is the layer we work in when we connect Salesforce to the rest of the campus, and it is where institutions consistently find integrations nobody has looked at in years.

The earlier risk: SOAP login is already off in new orgs

Most coverage of the Salesforce SOAP login retirement skips a change that has already happened.

Salesforce has published a separate release note titled "SOAP API login() Call is Disabled by Default in New Orgs." A user permission, Use Any API Auth, controls which users may authenticate with login(), and it is enforced by default in newly created orgs.

That creates a failure mode with a much shorter timeline than June 2027, and one that does not announce itself as an authentication change. A newly created org, a new Developer org, or a sandbox that comes back without the permission on the integration user will simply stop authenticating. The symptom is a login failure that looks like an expired password, and teams often spend a day or more on the wrong hypothesis before checking the permission.

The retirement itself will be less ambiguous. Salesforce states that requests will fail with an error indicating that the login() endpoint has been deactivated — a message that names its own cause.

Institutions therefore face two separate problems:

1. Near term. Establish whether Use Any API Auth is assigned to each integration user in every org you rely on, including sandboxes, and document it so refreshes and permission set rebuilds preserve it.
2. Longer term. Migrate every affected integration to OAuth before the June 2027 retirement.

Why the timeline is tight for higher education

For a scripted job the institution owns, the OAuth migration is well-defined work. The typical path is to configure an External Client App, generate a certificate, move the job to the JWT bearer flow, and establish a key rotation schedule. Done carefully, this is a matter of days. Salesforce also supports the OAuth client credentials flow for server-to-server work; we prefer JWT bearer because it authenticates with a signed assertion and a key you rotate on your own schedule, rather than a client secret that has to be stored and shared like the password you are replacing.

Vendor middleware is a different situation. Some older connector versions do not support JWT authentication at all. That means a product upgrade, which requires a change request, which at many institutions is tied to a budget cycle. Vendor timelines sit outside the institution's control.

The retirement also lands in June, coinciding with summer melt and fall census. An admissions or enrollment data feed failing during that window carries real operational and financial consequences.

If a vendor conversation is needed, it should begin in autumn 2026.

How to audit your Salesforce org for SOAP login() usage

Institutions can build a complete inventory of affected integrations from two sources inside Salesforce:

• Login History, filtered on the SOAP login type, shows which users are authenticating via login() and how often.
• API Total Usage event log gives a complementary view of API activity by user and method.

Salesforce also provides a test run in Release Updates that disables the SOAP API login() call in your org ahead of the retirement. Enabling it in a full-copy sandbox and running the normal integration schedule for a week will surface every integration that will fail in June 2027, in an environment where failure is recoverable.

From the resulting list, the work becomes a triage exercise:

• Institution-built integrations: migrate to OAuth, using the JWT bearer flow for server-to-server jobs.
• Vendor products: submit a version-upgrade request with a required completion date.
• Integrations with no identifiable owner: evaluate for decommissioning.

Institutions replacing a legacy SIS have a timing advantage here: the integration layer is being rebuilt anyway. If you are already planning a move from Banner, Colleague, or another legacy system, the authentication work belongs in that project rather than beside it.

Recommended action plan

1. Pull Login History filtered on SOAP logins and the API Total Usage log to build a complete inventory of affected integration users.
2. Check whether Use Any API Auth is assigned to each integration user in every org, including sandboxes, and document it so refreshes and permission set rebuilds preserve it.
3. Enable the retirement test run in a full-copy sandbox and run a full integration cycle.
4. Classify each integration as institution-built, vendor-managed, or unowned.
5. Open vendor upgrade requests in autumn 2026 with a firm deadline ahead of June 2027.
6. Schedule OAuth migration for institution-built integrations during a low-activity period in the academic calendar.

Institutions without the internal capacity to run this inventory are exactly who our managed services practice exists for — this is a scoped, finite piece of work with a fixed deadline.

Frequently asked questions

Is the Salesforce SOAP API being retired?

No. The SOAP API continues to function. The retirement covers only the login() call, which authenticates with a username, password, and security token. SOAP API calls made with an OAuth-issued session continue to work.

When does SOAP login() stop working?

In the Salesforce Summer '27 release, scheduled for June 2027, for API versions 31.0 through 64.0. It is already unavailable in API version 65.0 and later, and disabled by default in newly created orgs.

Does this affect our SIS integration with Banner, Colleague, Workday Student, or PeopleSoft?

Yes, through the middleware. The SIS does not authenticate to Salesforce itself. The ETL tool or connector that moves data between the SIS and Salesforce is what authenticates, and that is what needs to be reviewed and migrated.

What should integrations use instead of SOAP login()?

OAuth 2.0 through an External Client App. For unattended server-to-server integrations, the JWT bearer flow is the standard approach; Salesforce also supports the client credentials flow.

How do we know which integrations still use SOAP login()?

Review Login History filtered on the SOAP login type and the API Total Usage event log. Salesforce also provides a test run in Release Updates that disables the call, so affected integrations can be identified before June 2027.

What is the Use Any API Auth permission?

It is the user permission that controls whether a user may authenticate with SOAP API login(). It is enforced by default in newly created orgs, which is why a new org or a refreshed sandbox can break an integration that works in production today.

Next steps

Audit your ETL layer and anything custom that touches the Salesforce API. Confirm the Use Any API Auth permission is in place and documented, and schedule the OAuth migration for a quiet part of the academic calendar, because June 2027 will not be one.

Tondro Consulting works exclusively with higher education institutions on Salesforce implementation and integration. If you would like a second set of eyes on your integration user list before Summer '27, get in touch.

Source: Salesforce Winter '26 release notes, "SOAP API login() Call in SOAP API Versions 31.0 Through 64.0 Is Being Retired (Release Update)."