Enterprise Networking Guide
Multi-Branch and Cloud Workloads Need a Dedicated Outbound IP for Allowlists: What to Confirm Before Signing?
Explains why broadband redials and separate local internet breakouts invalidate partner allowlists, distinguishes outbound client requests from inbound callback notifications, and clarifies egress region, dedicated vs. shared use, retention period, and failover arrangements before signing.
When enterprises integrate with corporate banking APIs, e-tax systems, key customer supply chain portals, or overseas partner systems, the counterparty often requires registering a static public IP address (an allowlist) for security, permitting access only from that address. However, many teams with multiple branch offices, cloud workloads, or travelling employees find that a newly registered allowlist soon triggers an "unauthorised source IP" error, forcing finance and operations staff to repeatedly pause their work and submit change requests.
To resolve recurring allowlist failures across multiple locations, you do not need to provision an expensive static-IP dedicated line for every branch office. With our Enterprise Private Internet service, you can keep existing broadband at each location while aggregating only the business traffic that requires allowlist verification through a unified, identifiable egress IP. Clarifying the following key facts before planning and signing helps avoid rework after launch.
Why IP allowlists registered with partners stop working after a while
Everyday internet browsing in the office may work fine while the source IP address seen by a partner's backend keeps changing, usually due to several common situations:
- Standard broadband changes IP addresses after a reboot or automatic redial: The commercial broadband used by most branch offices does not come with a static address. Whenever the optical modem restarts after a power outage or the carrier redials during overnight maintenance, the outward-facing public egress IP changes accordingly.
- Carrier shared address pools (NAT) rotate addresses at any time: Some broadband lines pass through multiple layers of carrier network address translation (NAT). Even if the office router has not restarted, the carrier egress may randomly assign a different public IP from its address pool each time a new connection is initiated.
- Multiple branch offices, cloud hosts, and travelling employees connect separately: Finance staff at regional branches, application servers on Alibaba Cloud or Azure, and employees working from hotels or home all connect to the partner platform from different cities and networks, making it impossible for the partner to maintain a long, constantly changing list of addresses.
Distinguish outbound requests to partners from inbound webhook callbacks
When confirming API requirements with a partner, it is important to verify one thing upfront with their development or technical team: are our employees or servers initiating requests to the partner (outbound), or does the partner's server push notifications back to us (inbound webhook callbacks)? These two directions require completely different network and system configurations (industry technical documentation from Confluent Cloud and QuotaGuard also distinguishes between the two):
- Outbound requests (outbound source IP allowlist): Your offices, factories, or cloud servers actively initiate requests to call the partner's system, and the partner checks the source public IP of your outbound request. This is the exact scenario solved by a unified dedicated egress.
- Receiving partner callback notifications (inbound callback endpoint): For example, after a payment completes, a bank or payment platform actively pushes a completion notification to your server. This requires your server to expose a fixed public inbound endpoint (or open designated service ports through our application publishing capability), along with DNS resolution, security certificates (TLS), and signature verification configured by your development team; an outbound internet egress alone cannot directly receive unsolicited inbound pushes from external servers.
How we provide a unified, identifiable egress and four items to confirm before signing
When a partner requires a fixed source IP address, we can plan an identifiable internet egress for you: your branch offices, factories, and cloud environments continue using their existing local broadband to connect to our network (no new physical dedicated lines required, and faster provisioning than traditional dedicated lines). We route only the specific business traffic destined for that partner platform through a designated unified egress, while everyday web browsing and video traffic from employees continues to use local broadband at each site without interfering with one another.
Because "dedicated egress IP" can be interpreted differently in everyday discussions, we confirm the following four details with you in writing when designing the solution and signing the contract so that your registered allowlist remains reliable long term:
- Whether the egress IP is dedicated to your company or shared across multiple customers: Saying "static address" verbally does not automatically mean "dedicated to a single enterprise." If your partner platform has strict risk controls and you need to avoid being affected by other companies' traffic, the solution should explicitly specify whether a dedicated egress IP or a shared egress IP is used.
- The country and city of the egress IP: Many banks, government systems, and overseas partner platforms check not only whether an IP is on the allowlist, but also which country or city the IP belongs to. We confirm a matching egress region with you based on the partner platform's requirements.
- Contract retention period and advance notice for changes: No data centre or carrier resource should make an unconditional verbal promise that an IP will "never change forever." In our proposal and contract, we specify the period during which the address remains fixed, as well as the advance notice and coordination process in the event of major underlying carrier route adjustments.
- Allowlist registration for primary and backup egress failover: To prevent a single egress failure from causing business interruptions, critical workloads are typically configured with both a primary and a backup egress. When the primary egress encounters an issue and automatically fails over to the backup egress, the outbound source IP changes to the backup egress IP. Before launch, we provide both the primary and backup egress IPs so you can register both on the partner's allowlist in advance and verify during failover drills that both addresses pass validation smoothly.
Please also note that while a unified, stable egress IP resolves source identification at the network layer, account permissions, API rate limits, and business compliance requirements on the partner platform must still follow the partner's rules and applicable local laws and regulations.
Basic information to prepare for your initial consultation
- The type of external platform or partner requiring an IP allowlist (such as banking and payment systems, tax filing portals, supply chain portals, or overseas partner APIs), and whether there are country or city requirements for the egress location.
- Which cities your branch offices, factories, data centres, or public cloud environments that need to access the platform are located in.
- Whether your integration only requires your systems to initiate requests to the partner (outbound), or also requires receiving callback notifications pushed by the partner server (inbound); remaining details can be confirmed step by step during our consultation.