← Back to use cases

Stable outbound IP for webhook delivery

A SaaS partner expects callbacks from a fixed IP. Personal server gives you one.

You integrate with a SaaS that accepts webhooks only from a pre-registered IP allowlist. Your application servers sit behind a load balancer with a wide ephemeral IP pool — even cloud egress NATs change occasionally. Every IP shift breaks the integration until someone notices and re-registers.

A Personal server in QPOL gives you a single stable outbound. Your app servers route just the SaaS partner's hostnames through that node; everything else egresses normally. The partner pins your Personal server IP in their allowlist and the integration stops being a moving target.

This pattern also works for partner sandboxes that geofence by country. Need a UK egress for a UK-only API? Pick a UK Personal server. Need a Singapore egress because the partner's SDK fingerprints region? Pick Singapore. The control over outbound region is the whole point.

A practical caveat: do not put your entire production app behind one node. Personal server is one node, one IP — fine for outbound to specific partners, not fine as a single point of failure for all egress. Tunnel the integrations that need stability, leave the rest direct.

For high-availability needs (paired stable IPs in two regions), reach out via the Business form — that pattern is part of the team-pilot offering.