TL;DR
- The Update Instanced URLs in API Traffic release update enforces with Winter '27. It was first available in Summer '25 and was scheduled for Spring '26 before Salesforce postponed it, which is why some teams have already ignored it twice.
- What stops working is API traffic that uses an incorrect instanced URL, meaning a hostname like
na139.salesforce.comthat no longer matches the instance your org actually sits on. - Today Salesforce quietly routes that traffic anyway. After enforcement it does not, and the integration fails at the network layer before it ever authenticates.
- The fix is to call your org's My Domain login URL, then use the
instance_urlvalue that comes back in the token response rather than hardcoding a host. - You can control your own cutover. A My Domain setting blocks incorrect instanced URL traffic on demand, so you can force the failure in a sandbox this month rather than meeting it on upgrade weekend.
What You'll Learn
- What an instanced URL is, and what makes one "incorrect"
- Why this breaks after an infrastructure move you were never told about
- How to find the integrations still calling a hardcoded host
- How to use the My Domain block setting to schedule your own cutover
- The correct pattern: My Domain for login,
instance_urlfor everything after
The Problem
Salesforce orgs live on named infrastructure instances, and for years the API endpoint reflected that. An integration set up in 2019 might have been pointed at https://na139.salesforce.com/services/data/v52.0/, because that is what the org's instance was called, and it worked.
Then Salesforce moved the org. Instance migrations happen for capacity, maintenance, and hardware refresh, and they mostly happen without anybody in your team doing anything. Your org's instance name changed, the old hostname became wrong, and the integration kept working anyway because Salesforce has been tolerant about routing that traffic to the right place.
Winter '27 ends the tolerance. Shortly after your org takes the release, API traffic using an incorrect instanced URL is no longer supported, and the calls stop.
The reason this catches people is that nothing in your org changed to cause it. The integration was already pointed at the wrong hostname, potentially for years, and the only thing keeping it alive was a compatibility behaviour that is now going away. There is no warning banner on the integration, because from your org's perspective the traffic is arriving at the wrong door and always has been.
Common questions this article answers:
- What counts as an "incorrect" instanced URL, and how do I know if I have any?
- Why has this been postponed twice, and is it real this time?
- Can I test the failure before the release forces it?
Quick Answer
The Update Instanced URLs in API Traffic release update enforces with Winter '27, whose production upgrade dates on Salesforce Trust are 29 August, 5 September, 3 October, 9 October and 10 October 2026. After your org takes the release, API calls to an instanced hostname that does not match your org's current instance stop working. Fix it by pointing every integration at your org's My Domain login URL, for example https://yourcompany.my.salesforce.com, and by using the instance_url returned in the OAuth token response for subsequent API calls rather than storing a hostname in config. To find your exposure, search integration configuration and code for hostnames matching the old instance pattern such as na, ap, eu, or cs followed by digits, then check middleware connection settings, scheduled scripts, and anything using a saved session. To control the timing, enable the My Domain setting that blocks API traffic using an incorrect instanced URL, which forces the failure on a date you choose rather than on your upgrade weekend.
What an instanced URL is, and what makes one incorrect
An instanced URL embeds the infrastructure instance in the hostname:
https://na139.salesforce.com/services/data/v58.0/query
^^^^^^
the instance
A My Domain URL identifies the org rather than the hardware:
https://yourcompany.my.salesforce.com/services/data/v58.0/query
^^^^^^^^^^^
your org, wherever it happens to live
The distinction that matters is the word "incorrect". This release update is not about instanced URLs in general. It targets traffic to an instanced hostname that no longer corresponds to where your org lives, which is what you are left with after Salesforce migrates the org and your integration config stays where it was.
That framing tells you something useful about your risk. The older an integration is, and the longer your org has been running, the more likely it is to be affected, because it has had more chances to be moved out from under a hardcoded hostname. A brand new integration wired up last quarter almost certainly used My Domain, because that is what the modern setup guides tell you to do.
Finding what will break
There is no single Setup screen that lists every caller with a stale hostname, so this is a search across the places integration endpoints get written down.
Search your code and configuration. The instance naming pattern is distinctive: two or three letters then digits, on salesforce.com. Search repositories, deployment scripts, and any infrastructure-as-code:
# Find hardcoded instanced hostnames across a repo
grep -rnE "https://(na|ap|eu|cs|um|gs)[0-9]+\.salesforce\.com" . \
--include="*.java" --include="*.js" --include="*.py" \
--include="*.json" --include="*.xml" --include="*.yml" --include="*.properties"
Run the same search across your middleware exports. MuleSoft, Boomi, Informatica, Jitterbit and similar tools all store the endpoint in a connection configuration that can be exported and grepped, which is far faster than clicking through each connection in a UI.
Check the obvious human places too. Scheduled scripts on a server nobody logs into, a Postman collection shared across the team, a spreadsheet macro finance built, and a partner's integration you do not control. That last category deserves an email now rather than in October, because you cannot fix somebody else's config for them.
Review your Named Credentials. Anything calling Salesforce from Salesforce, or from a connected system through a Named Credential, has its endpoint recorded in one place. That is the easy win, and it is also a good moment to check whether those credentials are on the legacy format, which we cover in Migrating legacy Named Credentials.
The correct pattern
The fix is not simply swapping one hardcoded hostname for another. Hardcoding My Domain is better than hardcoding an instance, but the pattern Salesforce actually wants is that your integration learns its endpoint at authentication time.
When an integration authenticates, the token response includes the API host to use:
curl https://yourcompany.my.salesforce.com/services/oauth2/token \
-d "grant_type=client_credentials" \
-d "client_id=<consumer key>" \
-d "client_secret=<consumer secret>"
{
"access_token": "00D...",
"instance_url": "https://yourcompany.my.salesforce.com",
"token_type": "Bearer",
"issued_at": "1780000000000"
}
The instance_url in that response is authoritative. An integration that reads it and uses it for every subsequent call survives instance moves, org migrations, and this release update without anyone touching its configuration. An integration that ignores it and uses a stored hostname is one infrastructure change away from breaking again, whatever hostname you store.
So the migration has two steps, and the second is the one worth doing properly:
- Point the login and token request at your My Domain URL.
- Use the returned
instance_urlfor subsequent API calls instead of a value from config.
Most SDKs and connectors do step two automatically once they are given a My Domain login URL. Hand-rolled scripts and older middleware connections are where you find the stored hostname.
While you are in each integration's configuration, it is worth handling the OAuth username-password flow retirement at the same time, since it enforces in the same release and touches exactly the same set of connections. We cover that in Salesforce Retires the OAuth Username-Password Flow in Winter '27.
Choosing your own cutover date
This is the part most coverage of this release update leaves out, and it is the most useful thing in it.
Salesforce provides a My Domain setting that blocks API traffic using an incorrect instanced URL. Turning it on makes the failure happen immediately rather than at enforcement. That sounds like an odd thing to want until you consider the alternative: your upgrade weekend is fixed by Salesforce, likely falls on a weekend, and is the worst possible time to discover that a payroll integration has been calling a dead hostname since 2021.
A sensible sequence:
- Enable the block in a full sandbox and run a complete integration cycle, including monthly and quarterly jobs that would not appear in a week of testing.
- Fix what fails, working through the config and code inventory from the search above.
- Enable the block in production on a weekday morning of your choosing, with your integration owners on hand and the setting ready to switch back off.
- Leave it on. Once you are clean, the setting keeps you clean, and the release update becomes a non-event.
Step three is the whole point. You get a controlled, reversible, business-hours failure instead of an uncontrolled one, and if something unexpected breaks you turn the setting off and try again next week.
The one caveat is the periodic job. An integration that runs quarterly may not fail during your test window at all, so check your scheduler for anything with a long interval and either trigger it manually or verify its endpoint by inspection.
What your users will see
If this goes badly, users see data that stopped arriving rather than an error message, so the comms here are less about warning them and more about telling them how to report it:
Over the coming weeks we are updating how our connected systems talk to Salesforce, ahead of a platform change in October. If you use a report, dashboard, or list that is fed from another system, please check that the data still looks current and let us know quickly if it looks stale or stops updating. You will not see an error message if something goes wrong here. The symptom is data that quietly stops arriving, so a quick "this looks out of date" from you is genuinely the fastest way for us to catch it.
Send that to the people who own the downstream reports, not to everybody. The value is in recruiting the handful of people who would notice a stale number, and telling them explicitly that silence is the failure mode.
Frequently Asked Questions
Q: This was postponed from Spring '26. Will it be postponed again?
A: Possibly, and Salesforce has moved it once already, which is why some teams have deprioritised it twice. It is a poor thing to bet on, though, because the work is small and the failure is total. More usefully, the block setting means you do not need to care about the enforcement date at all: cut over on your own schedule and the release date stops being your problem.
Q: How is this different from Enhanced Domains?
A: Enhanced Domains changed the format of your org's My Domain hostnames and affected UI URLs, hardcoded links, and embedded content. This release update is narrower. It is only about API traffic that calls an instanced hostname which no longer matches your org's instance. An org that completed Enhanced Domains can still have integrations calling a stale instanced URL, so finishing one does not cover you for the other.
Q: Will this break the UI or bookmarks?
A: No. The change is scoped to API traffic. Users following a stale bookmark are handled by ordinary redirect behaviour and are not affected by this update.
Q: We use My Domain everywhere already. Are we safe?
A: Probably, but verify rather than assume. My Domain being enabled for user logins does not guarantee that every server-to-server integration was configured to use it, and the older ones are precisely the ones nobody has opened in years. Run the hostname search across your middleware exports and scripts before you conclude you are clean.
Q: When does my org actually hit this?
A: Shortly after your org takes the Winter '27 release. Salesforce Trust lists five major release dates: 29 August, 5 September, 3 October, 9 October and 10 October 2026. Most summaries mention only three of those, so check your instance on Trust for your specific date rather than working from an article, and see Setup then Release Updates for the enforcement status shown for your org.
Key Takeaways
- Winter '27 ends support for API traffic on an incorrect instanced URL, meaning a hostname that no longer matches your org's instance.
- Nothing in your org has to change for this to break you. The hostname went stale when Salesforce moved your org, and compatibility routing has been covering for it since.
- Find it by searching config and code, including middleware connection exports, scheduled scripts, Named Credentials, and partner-owned integrations.
- Use My Domain to log in and
instance_urlfor everything after, so the next infrastructure change does not break you again. - Use the My Domain block setting to pick your own cutover, turning an uncontrolled weekend failure into a controlled weekday one.
What's Next?
Recommended Reading:
- Salesforce Winter '27 Security Readiness: The Five Release Updates and the Sandbox Window to Test Them
- Salesforce Retires the OAuth Username-Password Flow in Winter '27
- Migrating legacy Named Credentials before they become the next deadline
- Connected app least privilege: granted versus used
Action Items:
- Grep every repository, middleware connection export, and script directory for instanced hostnames matching the
na/ap/eu/csplus digits pattern. - Repoint each one at your My Domain login URL and make it read
instance_urlfrom the token response instead of storing a host. - Enable the My Domain block setting in a full sandbox, run a complete integration cycle including long-interval jobs, then schedule the production cutover for a weekday morning.