The Salesforce Integration Deadlines Landing in 2027, and What to Audit Now

Between now and mid-2028, Salesforce is retiring four different ways your integrations authenticate or address the platform - and only one of them has a fixed calendar date. Treated individually, each is a routine release-note line item. Tracked as a set of Salesforce integration deadlines converging on the same two-year window, they're the reason a nightly sync, a middleware connection, or a custom Apex callout can go quiet with no warning anywhere in the Salesforce UI - because the break happens at the authentication step, before anything reaches a screen a person would look at.

The short answer

In brief: Salesforce is phasing out password-based OAuth logins, classic Connected App creation, SOAP's legacy login() call, and hardcoded instance URLs in API traffic, on four different timelines between late 2026 and 1 June 2028. None of it requires an emergency rebuild - most orgs' modern, middleware-based integrations (MuleSoft, Boomi, or similar, calling documented APIs, a pattern we covered from SAP's side in SAP's new API policy) are already fine. The actual risk is narrower and older: whatever custom script, legacy connector, or forgotten integration user was set up five-plus years ago and never touched again. Finding those before the deadlines find them for you is a half-day audit, not a project - close to the kind of gap a Salesforce Health Check is designed to surface alongside everything else nobody's looked at recently.

The Salesforce integration deadlines at a glance

Why these are landing as a cluster, not one event

All four trace back to the same instinct: Salesforce tightening what counts as a legitimate way to reach the platform, the same direction of travel we've seen from the other side of the wire too - SAP did something structurally similar to its own API surface this year. None of that makes any single item here urgent in isolation. What makes the set worth tracking together is that they share almost the same audit surface: a Login History review, a Connected Apps inventory, and a search through integration configs for hardcoded URLs answers three of the five questions in this table at once. Doing that audit once, now, is a better use of time than reacting to each deadline separately as its own fire drill over the next eighteen months.

The trade-off worth naming: it's tempting to treat this as a reason to rebuild every legacy integration this quarter. Don't. Migrating a working integration you haven't actually confirmed is at risk trades a known-working system for an unknown one, for no reason. Audit first, migrate only what the audit actually flags - which, for most orgs, turns out to be a short list rather than everything.

1. The OAuth username-password flow is the one to prioritise

This is the deadline that deserves first attention, for a reason that has nothing to do with severity and everything to do with certainty: it's a fixed calendar date, 20 February 2027, not tied to a release weekend that can slip. The instanced-URL update below has already been postponed three times - this one hasn't been, and Salesforce has explicitly structured it as calendar-based specifically so every org hits it on the same day regardless of upgrade schedule. Who should care: any org with an integration, script, or middleware connector authenticating by posting a username, password, and security token to get a token - a pattern common in integrations built five-plus years ago, before OAuth's client credentials and web-server flows were the obvious default. Who shouldn't worry yet: orgs whose integrations already use client credentials, JWT bearer, or web-server OAuth flows, which is increasingly the default for anything set up in the last two or three years.

2. New Connected Apps can no longer be created - this one's already live

Since Spring '26, Salesforce has blocked the creation of new Connected Apps in every org by default, whether through the UI or the API. Existing Connected Apps, including ones bundled inside installed packages, keep working - nothing breaks today. What changes is every new integration going forward: it has to be built as an External Client App (ECA) instead, Salesforce's replacement model with permissions and secrets split apart rather than bundled into one record. The practical risk here isn't a broken integration, it's a stalled project - a developer or partner who doesn't know the option disappeared, discovers the "New Connected App" button is greyed out mid-build, and loses a day figuring out why.

3. SOAP's login() call retires with the Summer '27 release

Separate from the username-password OAuth flow above, SOAP API's own login() operation - the older mechanism where an integration calls login() directly with credentials to get a session ID - is scheduled to stop working with the Summer '27 release, roughly June 2027. This one is easy to miss during an API-version audit, because the fix isn't a version bump: an integration can be calling a perfectly current SOAP API version while still authenticating through the retiring login() call. The check has to be about the authentication method, not the version number on the request.

4. Instanced URLs in API traffic: postponed again, but don't bank on a fourth delay

This is the deadline with the messiest history and the one worth double-checking against your own org rather than trusting any single article's date, this one included - it first appeared in Summer '25, was scheduled for Spring '26, and has now been pushed to Spring '27, its third postponement. Once enforced, API traffic still using a hardcoded instance URL (something shaped like na139.salesforce.com) instead of the org's My Domain login URL stops working - a real risk because Salesforce periodically moves orgs between instances for load-balancing, which silently invalidates anything hardcoded. You can test your exposure now, ahead of enforcement, by enabling "Block API traffic that uses an incorrect instanced URL" under My Domain in Setup and watching what breaks in a sandbox.

5. API versions 31.0-40.0 retire in 2028 - lowest urgency, still worth one check

The furthest-out item: Platform API versions 31.0 through 40.0 - covering REST, SOAP, and Bulk API calls - stop working entirely on 1 June 2028. For most orgs this is close to a non-issue; middleware platforms default to current API versions and get bumped through normal upgrades. It's worth exactly one check, not ongoing monitoring: confirm nothing in your integration layer is still explicitly pinned to a version number from a decade ago, which does happen with custom code nobody has touched since it was written.

What we're advising clients right now

Run the audit once, this quarter, rather than waiting for each deadline to arrive separately: pull Login History filtered for OAuth password logins, review Connected Apps OAuth Usage, and grep your integration configs for hardcoded instance URLs. For most orgs that turns up a short, specific list rather than a rebuild. Where it turns up more than that - or where nobody's confident they even know every integration currently authenticating against the org - that's exactly the gap an outside Salesforce architecture and integration review is built to close before a fixed date closes it for you. If you want a second opinion on what your own audit turns up, we're happy to look at it with you.

A few questions worth asking before the deadlines do

We don't use MuleSoft or similar middleware - are we still exposed?

Yes, arguably more so. Middleware vendors have every incentive to migrate their own connectors ahead of these deadlines, since a break affects every customer using that connector at once. A direct, point-to-point integration or a custom Apex callout built in-house doesn't have a vendor tracking these dates on your behalf - which is exactly why the audit needs to cover custom-built connections first, not just third-party tools.

Will Salesforce just postpone these again, like the instanced-URL one?

Possibly, for that specific item - it's already happened three times. Don't extend that assumption to the others by default. The OAuth username-password retirement was deliberately restructured as a fixed calendar date rather than tied to a release train specifically so it wouldn't drift the way a release-linked update can; treating it as equally likely to slip because a different, unrelated deadline has slipped before is the mistake worth avoiding here.

What's actually different between a Connected App and an External Client App?

A Connected App bundles OAuth settings, permissions, and secrets into a single record. An External Client App splits those apart - app configuration, policies, and secrets live separately - which is the main reason Salesforce is steering new integrations toward it: it removes the specific failure mode where anyone with edit access to one record can read or change both the app's permissions and its secret in the same place.

Who should actually own tracking these deadlines?

Whoever owns production support and the release calendar - not, by default, whichever developer originally built each integration, especially if that person has since moved on. That's the same single-point-of-failure pattern we've written about before: authentication details for an integration living in one person's memory rather than a shared, tracked inventory. Assign this to a role, not a name.

The bottom line

None of these four deadlines individually justifies an emergency response, and treating them that way - one fire drill per release note - is how an org ends up doing the same Login History review four separate times instead of once. The one date to actually anchor a calendar entry to is 20 February 2027, because it's the one that won't move. Everything else here is worth a single, shared audit this quarter: cheap now, and considerably less cheap the week a nightly sync stops for a reason nobody can see anywhere in the Salesforce UI.