An integration that’s run untouched for three years suddenly starts failing overnight — no error message inside Salesforce, no flag in a Flow, nothing in the debug log that points to a cause. The middleware just stops getting a response. Whoever built that integration left the company years ago, and the endpoint it calls was typed in once and never looked at again. That’s the exact failure mode behind Salesforce’s Winter ’27 instanced URL enforcement, and it’s why the question on every admin’s mind right now is whether their integrations will survive it. Cloud Nexus is fielding this exact question from clients mid-renewal right now, because the fix isn’t inside Salesforce at all — it’s buried in middleware configs and scripts nobody’s opened in years. This post covers what’s actually changing, where the risk hides, and how to find it before enforcement finds it for you.
Quick Answer: Salesforce is phasing out support for “instanced” API URLs — hostnames like na139.salesforce.com that point to a specific server instance — in favor of your org’s stable My Domain login URL. Once enforcement takes effect for your org, API calls aimed at the old instanced hostname stop being supported. The failure happens below your application layer, so Salesforce itself won’t show you a friendly error. This was originally planned for Spring ’26, got postponed, and is now rolling out in phases tied to Winter ’27, with a separate end-of-support schedule for exact dates. The integrations most at risk are the ones nobody’s touched in years: middleware configs, partner endpoints set up long ago, and scheduled scripts on servers outside Salesforce entirely. Our post on the OAuth username-password flow retirement covers a related Winter ’27 integration risk worth checking at the same time.
1. What Actually Counts As an “Instanced URL”
An instanced URL is any Salesforce API endpoint that hardcodes your org’s specific server instance instead of using your stable My Domain name. A typical instanced URL looks like https://na139.salesforce.com — the “na139” identifies the exact instance your org happens to sit on right now. Your org’s instance can change during routine maintenance, an instance refresh, or a migration to newer infrastructure such as Hyperforce. Your My Domain URL, by contrast, stays constant no matter which instance sits behind it.
Why it matters: Any integration, script, or connected app that was configured with the instanced hostname instead of the My Domain URL is exposed the moment Salesforce stops honoring that old hostname in API traffic.
2. Why Salesforce Is Enforcing This Now
Salesforce has been moving toward My Domain-based Enhanced Domains for years, and instanced URLs are the last piece still being cleaned up. Enhanced Domains apply your org’s company-specific My Domain name to every URL Salesforce hosts, which keeps those URLs stable even when the underlying infrastructure moves. Legacy redirections that used to quietly forward old instanced traffic to the right place have already been shut off in non-production environments, and production is following the same path. This enforcement was originally scheduled for Spring ’26, then postponed, and it’s now rolling out in phases tied to Winter ’27, with Salesforce publishing a separate end-of-support schedule for the exact cutover dates by org.
What to check: Don’t assume “postponed” means “later, not now.” Confirm your org’s specific enforcement date in Setup rather than working off a general release-notes timeline, since phased rollouts don’t hit every org on the same day.
3. Where These Hardcoded URLs Usually Hide
The integrations most likely to break are the ones that live outside Salesforce entirely, which is exactly why they’re easy to miss. Middleware configuration files often have an instanced URL typed in once during initial setup and never revisited. Endpoints wired into a partner or vendor system years ago frequently point at an old instance name nobody remembers choosing. Scheduled scripts running on a server maintained by a former employee are a classic source, since nobody currently on staff knows the script exists until it starts failing.
Fix: Audit every API endpoint across your middleware, connected apps, named credentials, and any custom scripts calling the Salesforce API, and replace hardcoded instance hostnames with your org’s My Domain login URL. This is precisely the kind of cross-system integration audit Cloud Nexus runs as part of a Salesforce org review — the risky endpoints are almost never inside Salesforce itself, so the audit has to extend into your middleware and any point-to-point connections, which is the same ground we cover when helping clients decide between a full MuleSoft implementation and lighter integration tooling.
4. How to Test Before Enforcement Hits You
Salesforce gives you a way to find broken integrations on your own schedule instead of finding out during enforcement. Your org’s My Domain settings include an option that blocks API traffic using an incorrect instanced URL, which you can enable in a sandbox to see exactly what breaks. Enabling this setting briefly caused a separate issue with SOAP login URLs inside Visualforce pages in early 2026, but Salesforce resolved that issue by mid-year, so testing now is safe. Running this test in a full sandbox first gives you a list of exactly which integrations fail, instead of guessing.
Fix: Turn on the “block instanced URL API traffic” setting in a sandbox, run your normal integration and batch job schedule for a few days, and treat anything that errors out as confirmed at-risk in production. Fix and retest those specific integrations before touching the same setting in your production org.
Frequently Asked Questions
What’s the difference between an instanced URL and a My Domain URL?
An instanced URL, like na139.salesforce.com, names the specific server instance your org currently runs on. A My Domain URL, like yourcompany.my.salesforce.com, is your org’s own stable address, which stays the same even when Salesforce moves your org to a different instance behind the scenes.
Is there a hard deadline for this enforcement?
Not a single universal date. This change was originally planned for Spring ’26, was postponed, and is now rolling out in phases tied to Winter ’27, with Salesforce publishing a separate end-of-support schedule by org rather than one global cutoff. Check your own org’s My Domain settings and release update schedule rather than relying on a general timeline.
Does this affect Named Credentials and Connected Apps, or just custom API scripts?
It can affect either. Any Named Credential, Connected App, or custom integration that was configured with an instanced hostname instead of your My Domain URL is exposed, regardless of whether it’s a formal Salesforce configuration object or a hardcoded value in an external script.
How do I get started auditing our integrations for this?
Start by enabling the setting that blocks instanced-URL API traffic in a full sandbox, then run your normal integration schedule for a few days to see exactly what fails. From there, work outward into middleware configs, partner endpoints, and any scheduled scripts outside Salesforce, since that’s where hardcoded instance URLs most often hide.
Not Sure Which of Your Integrations Still Use a Hardcoded Instance URL?
Not Sure Which of Your Integrations Still Use a Hardcoded Instance URL?
Book a free 90-minute Salesforce Org Review with the Cloud Nexus team. We’ll help you sandbox-test the instanced-URL enforcement setting, trace every middleware and partner endpoint that touches your org, and give you a prioritized list of what to fix before enforcement reaches your instance.
Book Your Free Org Review →
