Snowsight: New account-specific host for sign-in traffic (Pending)¶
Starting October 16, 2026, Snowsight changes the host that it uses to complete sign-in and
to make subsequent API calls when users reach Snowflake through app.snowflake.com. The new host is
specific to your account.
If your organization restricts outbound web traffic with a firewall, forward proxy, or network allowlist, an administrator must allow the new host before this change reaches your account. Otherwise, users in your organization can’t sign in to Snowsight.
Important
All information on this page, including the planned date, is subject to change.
Does this change affect your account?¶
What determines whether you need to act is how your users reach Snowsight, not whether your account has Private Link configured. An account can have Private Link configured and still have users who reach Snowsight over a public connection.
| How your users reach Snowsight | Action required |
|---|---|
| Over a public connection, and outbound web traffic is filtered by a firewall, forward proxy, or allowlist | Yes. Add the new host. See What you need to do. |
| Over a public connection, and outbound web traffic isn’t filtered | No. |
| Over Private Link (AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect) | No. This change doesn’t affect Private Link traffic. |
| Some users over Private Link, others over a public connection | Yes, for the public connections. Private Link sessions are unaffected. |
Behavior change¶
- Before the change:
Snowsight completes sign-in and subsequent API calls through a shared host that isn’t specific to your account, in the following form:
- After the change:
Snowsight completes sign-in and subsequent API calls through a host that is specific to your account, in the following form:
The existing apps-api.c1.<region>.<cloud>.app.snowflake.com host continues to be used and must
remain in your firewall, proxy, or allowlist configuration. The new host is additional, not a
replacement. Don’t remove the existing host.
Why Snowflake is making this change¶
The shared apps-api host isn’t specific to your account, which prevents Snowflake from routing
Snowsight sign-in traffic through the same infrastructure tier that serves your account’s
other traffic. Moving to an account-specific host lets Snowflake route this traffic closer to your
account, which improves sign-in latency and reliability.
What you need to do¶
Complete these steps before the change reaches your account if both of the following are true:
- Some of your users reach Snowsight over a public connection. This is the case even when your account also has Private Link configured.
- Your organization filters outbound web traffic with a firewall, forward proxy, or network allowlist.
If all of your users reach Snowsight over Private Link, no action is required. The change doesn’t affect Private Link traffic.
1. Find the new host for your account¶
Run the following statement in your Snowflake account:
In the output, find the entry where type is ACCOUNT_PUBLIC. Its host value is the new host for
your account, in the form <org-account>.<region>.<cloud>.snowflake.com.
2. Add the new host to your network configuration¶
Allow outbound HTTPS to the new host in every place that filters your users’ web traffic, which can include:
- Corporate firewall rules
- Forward proxy or secure web gateway allowlists
- Browser or endpoint policy allowlists
- Zero-trust network access (ZTNA) or SASE policies
Keep the existing apps-api.c1.<region>.<cloud>.app.snowflake.com host in place. Both hosts are
required.
3. Validate that the new host is reachable¶
From a machine on your corporate network, open the following URL in a browser, replacing
<new-host> with the host value from step 1:
A successful result is an HTTP 200 response with a body of the following form:
If the request is blocked, times out, or returns a proxy error page, the new host isn’t yet allowed on that network path. Revisit step 2.
Important
A successful validation confirms only that the network path you tested from can reach the new host. It doesn’t confirm that every user can.
If your own network access is broader than that of other Snowflake users in your organization — for example, because you’re on a different network segment, VPN profile, proxy policy, or device posture group — your test can succeed while other users are still blocked. Validate from a representative sample of the network paths and user populations that access Snowsight, including remote users and any users on more restrictive policies.
If users are blocked after the change¶
Users whose network path doesn’t allow the new host can’t sign in to Snowsight. To confirm the cause, have an affected user run the validation in step 3 from their own machine. If that request is blocked, add the new host to the policy that applies to that user, then retry.
If you have questions about this change, open a case with Snowflake Support and reference this behavior change.
See also¶
Ref: 2413