If your integrations still authenticate with SOAP API login(), Salesforce just put you on a countdown clock. Summer '27 is the hard stop — and migration is not a weekend project.
This is the fast, action-focused companion to our full Salesforce SOAP API login retirement migration guide. Use it to find out whether your org is affected and what to do next.
Quick Answer
Salesforce is retiring the SOAP API login() call in API versions 31.0–64.0 with the Summer '27 release. It is already unavailable in v65.0+ and disabled by default in new orgs. Any integration that signs in with a username, password, and token must move to OAuth 2.0 and External Client Apps before the deadline.
TL;DR
- What's ending: SOAP API
login()(username-password auth) in API versions 31.0–64.0, retiring with Summer '27. - Already gone:
login()is unavailable in v65.0+ and off by default in new orgs. - What to do: Audit every integration, then migrate to OAuth 2.0 flows and External Client Apps.
- Why it's urgent for regulated firms: A broken integration is not just a bug — it can become a compliance event.
- Vantage Point relevance: Our integration and security teams run authentication audits across Salesforce, middleware, and vendor connections.
What Is Changing With SOAP API Login?
Salesforce is removing the SOAP API login() operation — the method that authenticates by passing a username, password, and security token to get a session ID. In API versions 31.0–64.0 it retires with Summer '27. In v65.0 and later it is already unavailable, and new orgs have it disabled by default.
Salesforce is also moving customers toward a permission-based control and its newer External Client Apps framework — a secure-by-default model for connected integrations. Confirm exact timing in your org's release notes, as Salesforce has adjusted interim control dates.
Why This Matters More Than You Think
Most orgs do not actually know which integrations rely on SOAP login(). The risk hides in custodian feeds, middleware jobs, and legacy ETL scripts no one has touched in years.
For regulated firms, the stakes are higher. A failed data sync can mean missing records, broken reporting, and audit gaps — a compliance event, not just an outage. And third-party vendors may not upgrade to OAuth on your timeline, leaving you exposed.
Is Your Org Affected? A 60-Second Self-Check
Check any that apply. One or more "yes" answers means you have migration work to do.
- [ ] We use Data Loader, MuleSoft, Informatica, Jitterbit, Boomi, or Talend with username-password auth.
- [ ] We have custom Java, .NET, Python, or PHP scripts that call Salesforce
login(). - [ ] We receive custodian, market-data, or partner feeds through legacy middleware.
- [ ] We have integrations built before 2015 that no one has reviewed recently.
- [ ] We are unsure which connected apps use OAuth versus SOAP login.
If you checked the last box, start with an audit before anything else.
The 5-Step Migration Playbook
| Step | Action | Goal |
|---|---|---|
| 1. Audit | Use Event Log Browser and Login History to find every SOAP login() call |
Full inventory |
| 2. Classify | Separate custom-built integrations from third-party vendor tools | Know who owns each fix |
| 3. Map to OAuth | Choose Client Credentials (server-to-server) or Web Server Flow (user context) | Right flow per use case |
| 4. Migrate | Move to External Client Apps — Salesforce's secure-by-default model | Modern, compliant auth |
| 5. Test & monitor | Validate in sandbox, then monitor login events in production | Zero silent failures |
Why Orgs Get This Wrong
- Shadow integrations no one documented still run in production.
- Middleware configs for MuleSoft or Workato are buried in legacy setups.
- Vendors drag their feet on OAuth support, so you discover the gap too late.
What Businesses Should Do Next
Start the audit now. With roughly a year until the deadline, orgs with 10 or more integrations should budget several weeks for migration and regression testing — especially across sandbox and staging, which teams often forget to update.
If your team is evaluating how this applies to Salesforce, integrations, or CRM governance, Vantage Point can help assess the right next step and build a practical migration plan.
How Vantage Point Helps
Vantage Point's complimentary Salesforce health check can include an integration authentication audit — identifying every at-risk login() call across your org and middleware. Our system integration and data migration team then maps each integration to the right OAuth flow, while our compliance and security specialists ensure the change strengthens your audit posture. For ongoing coverage through the deadline, our managed services and ongoing support team monitors and maintains the new configuration.
FAQ
Is Salesforce retiring the entire SOAP API?
No. Only the login() authentication call is retiring. The SOAP API itself still works for data operations — you just need to authenticate with OAuth 2.0 instead of a username and password.
When exactly does SOAP API login() retire?
The login() call in API versions 31.0–64.0 retires with the Summer '27 release. It is already unavailable in v65.0+ and disabled by default in new orgs.
What happens if we miss the deadline?
Integrations that rely on SOAP login() will stop working. Calls fail, syncs break, and automated jobs halt — often silently, which is especially risky in regulated environments.
What should we migrate to?
Move to OAuth 2.0 flows hosted in External Client Apps. Use Client Credentials or JWT Bearer for server-to-server integrations and the Web Server Flow when user context is required.
Do we need to act if we already use OAuth?
No. Integrations already using OAuth 2.0, JWT Bearer, or Named Credentials are compliant. Run the self-check above to confirm nothing legacy is still in play.
How do we find every integration using SOAP login?
Use the Event Log Browser (API Total Usage logs) and Login History in Setup, filtered for SOAP Enterprise or Partner entries. Vantage Point can run this audit for you as part of a complimentary health check.
