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.
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.
login() (username-password auth) in API versions 31.0–64.0, retiring with Summer '27.login() is unavailable in v65.0+ and off by default in new orgs.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.
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.
Check any that apply. One or more "yes" answers means you have migration work to do.
login().If you checked the last box, start with an audit before anything else.
| 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 |
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.
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.
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.
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.
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.
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.
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.
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.