Hyperforce is designed for backward compatibility, but it’s necessary for some users to take extra steps to preserve their Salesforce connections.
Hyperforce uses modern, cloud-based technologies that require you to adopt technical best practices to maintain connectivity with Salesforce. These best practices also apply to first-party infrastructure, where many are optional. On Hyperforce, they’re mandatory.
In summary, the requirements are:
We recommend that you review your orgs, and if necessary, make one-time changes to adopt these practices before upgrading to Hyperforce.
This table summarizes the symptoms that occur when connection-related requirements aren’t met, and their resolutions.
|
Technical Requirement |
User Scenario |
Hyperforce Symptom |
Resolution |
|---|---|---|---|
| Don’t use hard-coded instance references | You have hard-coded instance references within a Salesforce org, or call a Salesforce endpoint with hard-coded instance references from an external API client | The API calls fail to connect to the customer org and return API errors. | Update hard-coded references following org migration best practices. See How to Prepare for an Org Migration. Enable the My Domain setting Stabilize Visualforce, Experience Builder, Site.com, and content file URLs. |
| You use Marketing Cloud Connect and don’t have Tenant-Specific OAuth Endpoint (TSOE) enabled | Marketing Cloud Connect features such as Tracking don’t work as expected. Expired Marketing Cloud API tokens. | Enable Marketing Cloud Connect Tenant Specific Oauth Endpoint (TSOE) | |
| You use generic Marketing Cloud Engagement endpoints with hard-coded instance information | API calls to Marketing Cloud Engagement endpoints fail or return errors. | Update Marketing Cloud Engagement endpoints to tenant-specific endpoints | |
| Don’t use hard-coded IP allowlists. With the exception of email relays - see the “Hyperforce - Email Relay” table in this article | You use IP address allowlists to enable connections from your corporate network into Salesforce. | Users and API clients can’t access Salesforce services from within your corporate network | Allowlist required domains instead of IP addresses. |
| You use IP address allowlists to enable connections from Salesforce into your corporate network. Examples: Web service endpoints, OData connections | Callouts from Salesforce don't reach your hosted web services or endpoints. |
Use modern security mechanisms for authentication and authorization. Examples: 2-way SSL (mTLS), Auth Provider, and Connected apps. If you are a Government Cloud Plus customer, see IP Addresses to Allow for Government Cloud Plus. | |
| You use IP address allowlists to filter emails from Salesforce services. | Emails are blocked or treated as spam. | Use industry-standard email security mechanisms supported by Salesforce such as SPF/DKIM/DMARC. | |
| Implement an equivalent solution to Salesforce Express Connect | You use Salesforce Express Connect (sold through partner telecom service providers) and want direct connectivity to Hyperforce. | Salesforce Express Connect (SEC) does not provide direct network connectivity to Hyperforce. | Customers that use SEC and want direct network connectivity to Hyperforce must contact their SEC telecom service provider(s) to acquire and implement an equivalent network service before their migration. The recommended solution uses AWS Direct Connect (DX) with a Public Virtual Interface (VIF) to create a secure connection. Find guidance in Set Up AWS Direct Connect (DX) for Hyperforce and How to Access Salesforce Hyperforce Securely and Reliably with AWS Direct Connect. This solution is in addition to, not a replacement for, SEC. |
| Include Service Name Indication (SNI) for HTTPS handshake success | You use API clients that don’t include SNI in the TLS ClientHello message | The HTTPS handshake fails with SSLHandshakeException or a similar error. | Choose one of - Include SNI in the TLS ClientHello message OR - Use a Salesforce API endpoint in *.my.salesforce.com or *.sandbox.my.salesforce.com |
| You send requests to *.cloudforce.com or *.database.com | The HTTPS handshake fails with SSLHandshakeException or a similar error. | Enable Enhanced Domains to redirect traffic addressing those domains to *.my.salesforce.com | |
| You have a Salesforce Experience Site and use custom domains that are served by a third party CDN. The CDN doesn’t send SNI, or sends the custom domain instead of the originating *.my.salesforce.com domain. | CDN throws an exception, and the Salesforce Experience Site doesn’t load. | Configure the CDN to NOT use SNI, and ensure the CDN expects an HTTPS certificate that includes *.my.salesforce.com in its Subject Alternative Name (SAN) list. | |
| Don't pin certificates | You have pinned your mobile application to the entity certificate or a CA certificate in the certificate chain. | Your mobile application fails to log in. See What Your Users See | Turn off mobile application pinning. See Configure Authentication Server Certificate Pin |
| You have pinned your APIs to only trust the entity certificate or a CA certificate in the certificate chain. | Your API calls fail. | Remove certificate pinning from your custom configuration. If you must pin, create a pinset that includes the entire Mozilla Server Authentication (SSL/TLS) Root Certificates list. | |
| Use .NET version 5.0 for Platform Events and Streaming Clients | Your org has Platform Events or Streaming Clients, and your .NET version is less than 5.0 | Operations fail with error 403 - 403: Organization total events daily limit exceeded OR - 403: Unknown client | Upgrade to .NET version 5.0 or higher. More details can be found in Microsoft's .NET documentation here. |
| Encode non-ASCII characters in URIs | You pass a URI with unencoded, non-ASCII characters to a REST API | The API returns Error 400: Bad Request | Encode all non-ASCII characters in accordance with RFC-3986 |
| Update the target hostname for custom domains served by a third-party service or content delivery network (CDN) | You have a custom domain that is served by a third-party service or CDN | Your site content doesn't load on your custom domain | Work with the third-party to update the target hostname as described in Prerequisites for a Custom Domain That Uses a Third-Party Service or CDN. |
| When using REST APIs, limit your URI and headers to less than 16K | You exceed the Salesforce-documented limit and pass a REST API call that uses more than 16K in its combined URI and headers | The API returns error 431: Request Header Fields Too Large or 414: URI Too Long | Keep the combined length of your URI and headers under 16K. To pass long SOQL or SOSL queries, use the Composite feature. |
Salesforce best practices discourage using hard-coded instance names in endpoint references.
Even in first-party infrastructure, migration that changes an org’s instance sometimes causes access disruptions if instance names are hard-coded. In public cloud, the same flexible infrastructure that enables desirable capabilities like dynamic scaling also makes it more likely that org migrations and instance maintenance include an instance change. To avoid disruptions during routine maintenance, hard-coded instance references aren’t permitted in Hyperforce.
Follow these documented best practices to identify and remove hard-coded references from your implementation:
You can read more about these recommendations in Updating Hard-Coded References.
Marketing Cloud Engagement customers must enable tenant-specific OAuth endpoints. To learn more, read and follow these instructions:
Other products that migrate to Hyperforce also will disallow hard-coded instance references. We recommend that you seek out and update instance-based hard-coded references that are used with those other services in anticipation of the product’s move to Hyperforce.
Because of the dynamic nature of cloud environments, Salesforce recommends using mTLS as described in Preferred Alternatives to IP Allowlisting on Hyperforce, rather than IP allowlists.
The next section describes specific use cases where allowlisting was routinely used, with suggested alternatives.
If you use IP allowlists to control user or server access into Salesforce, then Allow the Required Domains.
Secure access to Salesforce domains is enforced through the use of HTTPS and SSL client certificates.
If you use IP allowlists to filter requests from Salesforce callout features into your corporate network's hosted web services or API endpoints, be aware that allowlisting verifies the source of the request but not its authenticity. Also, these IP addresses are used by multiple customers and trial orgs; they are not unique to a single customer. For these reasons, allowlisting is insecure. Requests can include the following types:
Instead of allowlisting, implement modern authentication and authorization (AuthN/AuthZ) for your web services and API endpoints to ensure that only your org can access your network.
Salesforce offers these features to help you integrate security with AuthN/AuthZ:
Customers who use IP allowlists must allow all of the official Hyperforce IP ranges, which can be found in JSON format at the URL https://ip-ranges.salesforce.com/ip-ranges.json. For a full explanation and best practices, read Hyperforce IPs to Allow - Sales, Service, Industries, and Tableau Clouds.
Included Services
The JSON list includes IPs for inbound connections to Hyperforce from external sources, including some for Salesforce Edge, as well as IPs for outbound connections from Hyperforce to the customer’s network. These addresses are for products built on the Salesforce platform including Sales, Service, Industries, and Tableau Clouds, and for the MuleSoft Anypoint Platform
Excluded Services
The JSON list excludes IP addresses for these services: Email, Marketing Cloud, Commerce Cloud, and Slack.
If you are a Government Cloud Plus customer, see IP Addresses to Allow for Government Cloud Plus.
If you use IP allowlists to bypass email blocking rules, then adopt standard email security protocols such as Transport Layer Security (TLS), Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), or Domain-based Message Authentication, Reporting, and Conformance (DMARC). Salesforce fully supports all of these options.
NOTE: While we do not recommend the use of IP allowlists for emails in general, IP addresses used by email relays on Hyperforce are more static and you can use them for your email relay needs if necessary. Those email relay IP addresses are listed in the “HYPERFORCE - Email Relay” table in Ensure you can receive email from the Salesforce application.
Find more information in these articles:
Salesforce Express Connect (SEC) provides direct network connectivity to first-party SFDC infrastructure, but not to Hyperforce, which runs on Amazon Web Services (AWS). If you need a direct connectivity solution on Hyperforce for regulatory, security, or other reasons, we recommend AWS Direct Connect (DX). Salesforce doesn’t sell SEC or DX. Contact your telecom provider to set up these services. In most cases, the SEC telecom provider is also an AWS DX provider. Read more in Set Up AWS Direct Connect (DX) for Hyperforce and How to Access Salesforce Hyperforce Securely and Reliably with AWS Direct Connect.
Some Salesforce services such as login.salesforce.com and *.force.com and Marketing Cloud run in our first-party infrastructure. To maintain connectivity to all Salesforce services in first-party and Hyperforce, customers who require direct network access to Salesforce must continue to run SEC and add AWS DX. Global login endpoints are being relocated to Hyperforce in the near future. Read more in Salesforce Express Connect (SEC) Users - Prepare for Global Login Endpoint Changes.
In Hyperforce, each Salesforce domain has a separate HTTPS certificate. Web browsers and API callers must specify the desired domain by including SNI in their ClientHello message, or else they can address one of the default domains.
Read more about the detailed SNI requirements, issues, and solutions in:
Resolve HTTPS/SSL connection errors in Hyperforce with SNI.
Certificate pinning is the practice of selecting a single certificate to trust. Pinning is an outdated security practice that adds operational complexity and risks outages. Salesforce doesn't support pinning in Hyperforce. Hyperforce always employs SSL/TLS and rotates its certificates regularly. All Hyperforce certificates chain to Certificate Authorities (CAs) included on the Mozilla Server Authentication (SSL/TLS) Root Certificates list.
If you are pinning certificates in the mobile application, disable the pin by following the instructions in Configure Authentication Server Certificate Pin. If you are pinning another way, discontinue the practice. If you have an insurmountable need to pin a certificate, create a pinset that contains the entire Mozilla Server Authentication (SSL/TLS) Root Certificates list.
Orgs with Platform Events or Streaming Clients must use .NET version 5.0 or higher. Lower .NET versions might lead to disruptions to these features due to Hyperforce RFC compliance requirements. More details can be found in Microsoft's .NET documentation here.
When passing a URI to Salesforce using a REST API, you must properly encode all non-ASCII characters using RFC-compliant percent encoding. Hyperforce has a stringent underlying architecture that doesn't permit passing unencoded characters. You can find more information about proper encoding in the RFC-3986 specification, and helpful tips in W3School's HTML URL Encoding Reference.
A custom domain serves your Digital Experiences or Salesforce Sites on a domain that you own, such as https://www.example.com.
If your custom domain uses the “Use a third-party service or CDN to serve the domain” domain configuration option, the required configuration for that domain changes during these events.
As part of planning for those events, work with your third-party provider to update the target host name for your domain immediately after the change. Otherwise, your custom domain stops working.
To determine if you have a custom domain that uses that configuration option, visit the Domains page in Setup.
To determine whether your org is on Salesforce Edge Network, visit the My Domain page in Setup.
For instructions about setting the target host name for your custom domain that’s served by a third-party service or CDN, see the in the Point Your Custom Domain to Your Org with Your Target Hostname section of Prerequisites for a Custom Domain That Uses a Third-Party Service or CDN.
For your REST API calls, the combined size of the URI and HTTP headers must not exceed the documented 16 KB limit.
Salesforce reserves additional space for its own purposes. This buffer is not for customer use and can change at any time. However, the errors for exceeding the limit--414 URI Too Long and 431 Request Header Fields Too Large--are returned when the request exceeds the combined size of 16 KB plus the Salesforce buffer. This means you may be unknowingly exceeding the documented limit.
To support advanced network features, Hyperforce may consume more of the reserved space than first-party (1P) does. Therefore, API calls that currently succeed on 1P despite exceeding the 16 KB limit may fail on Hyperforce. This isn't a Hyperforce limitation; it's an enforcement of the existing, documented limit. To avoid service disruptions, your application must strictly adhere to the 16 KB limit. Requests that exceed this limit may fail without notice, even if they initially work on Hyperforce.
If you receive either error, your API calls are significantly over 16 KB. Common culprits are long SOQL or SOSL queries. To avoid errors, send long requests using the Composite feature.
We recommend that you review the Content File Preview Issues article and understand workarounds. This issue affects both Hyperforce and first-party users.
|
Date Revised |
Revisions |
| October 22, 2025 | Updated information about the Hyperforce IPs. The JSON file now contains IP addresses for inbound connections, as well as outbound connections. |
| October 8, 2025 | Updated Salesforce Express Connect Considerations section to mention upcoming relocation of global login endpoints. |
| September 16, 2025 | Updated instructions relating to custom domains served by a 3rd party CDN |
| September 2, 2025 | Minor update to certificate pinning advice. Clarified to create a pinset for the entire Mozilla list. |
| August 27, 2025 | Added instruction to respect 16KB REST API limit for URI and HTTP headers. |
| June 23, 2025 | Updated information regarding AWS DX as an alternative to SEC. |
| December 5, 2024 | Updated section Don't Use Hard-Coded IP Allowlist with new location for Hyperforce egress IPs. |
| May 24, 2024 | Removed Tableau from the list of products for which Hyperforce IPs are unavailable. |
| May 23, 2024 | Removed Temporary Limitations Table. All open issues being tracked are resolved. |
| May 7. 2024 | Revised SEC notes and added AWS DX guidance. Added instructions for custom domains. |
| February 9, 2024 | Added URL encoding requirements |
| January 16, 2024 | Removed Streaming API requirements |
| December 7, 2023 | Removed temporary limitations for: High Scale Orders, Service Cloud Voice, Event Relay, Salesforce Payments |
| October 20, 2023 | Added Streaming API version requirements. Updated several dates in Temporary Feature Limitations. |
| August 18, 2023 | Updated tools for finding hard-coded references. |
| August 10, 2023 | Added requirement to not pin certificates. Clarified branding "Marketing Cloud" to "Marketing Cloud Engagement." |
| July 14, 2023 | Update to Service Cloud Voice known issues. |
| June 8, 2023 | Additional clarification regarding Hyperforce IPs. Update known issues dates for High Scale Orders, Service Cloud Voice, and Event Relay, and add Salesforce Payments. |
| April 26, 2023 | Modified stance re: Hyperforce IPs and added link to download location. Promoted implementing a replacement for Salesforce Express Connect from being a Temporary Known Issue to a full-fledged requirement, and added more information. Updated links for ApexREST service headers. |
| February 1, 2023 | Removed Custom HTTPS certificates from Temporary Known Issues |
| January 26, 2023 | Added Event Relay to Temporary Known Issues |
| December 8, 2022 | Changed RFC 2616 to 7230 for Non-Compliant ApexREST service headers |
| October 20, 2022 | Grouped temporary known issues into table, updated list, and added target resolution dates. Added .NET 5.0 requirement for Platform and Streaming Events. |
| September 9, 2022 | Removed http 1.1 requirement |
| August 19, 2022 | Added ApexREST and .NET information in Temporary Known Issues |
| August 9, 2022 | Updated approved verbiage in IP Allowlisting section. |
| July 28, 2022 | Added recommendation to use Enhanced Domains to resolve SNI issues with *.cloudforce.com or *.database.com |
| March 24, 2022 | Updated Estimated time to resolution for Custom Domains using Custom HTTPS Certificates |
|
February 21, 2022 |
Added clarification about the use of IP allowlisting for email relay functionality in Hyperforce - that IP addresses used for email relay on Hyperforce is more static and you can use them for your email relay needs if necessary. |
|
December 30, 2021 |
Document created. |
000392992

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.