Static Outbound IPs for Webhook Allowlisting

A static outbound IP means every webhook we forward leaves from the same known address, so a destination sitting behind a corporate firewall can put that one address on its webhook IP allowlist instead of a whole cloud region. It solves a delivery problem, not a trust problem. An allowlist tells a firewall which connections may pass and says nothing about whether a request is genuine; signature verification answers that.

The need comes up almost exclusively when your customer’s security team owns the endpoint you deliver to and their default posture is deny. Your retry policy is irrelevant until the packet gets through.

The blocker

An ERP, a claims system, or an internal order service sits inside a corporate network, reachable through a reverse proxy or a WAF. The rule in front of it is an allowlist (older firewall documentation calls it a whitelist): traffic from a named set of source addresses is accepted, and everything else is dropped at the edge.

You point a destination there and deliveries fail. The log is unhelpful by design: connection timeouts, a TLS handshake that never completes, or a generic 403 from an edge device. There is no application error because the request never reached the application. The destination team checks their logs, sees nothing, and reports that everything is fine on their side. Both statements are true at once.

This is also why the failure is easy to misread as a delivery bug: the events queue up, retries burn through their backoff schedule, and everything lands in the dead letter queue with a timeout that explains nothing. The fix is administrative: someone adds your source addresses to a rule. That is a change request, it sits in a queue, and it gets rejected if it is vague. And on most cloud setups, vague is all you can offer.

Why shared cloud egress breaks allowlisting

If your delivery workers run on a typical cloud setup, you cannot tell anyone with confidence which address your requests come from.

Worker pools scale up and down. Instances get rescheduled onto different hosts. A managed NAT gateway sits in front of a pool of addresses and picks one per connection. Serverless is worse: the egress address can differ between two invocations a second apart. None of this is a fault. Elasticity works this way.

The usual workaround is to hand over the cloud provider’s published egress ranges. Those documents exist, and they are enormous: hundreds of prefixes covering every tenant in a region. A team that allowlists them has allowlisted every other customer of that cloud, including whoever signs up for a trial this afternoon. Some reviewers refuse outright. The ones who accept have turned a specific rule into a broad one, which is arguably worse than no rule, because it still looks like a control on paper. And those ranges change, so unless the destination team automates ingestion of the feed, the rule drifts out of date and deliveries start failing on a Tuesday for no visible reason.

What a static outbound IP gives you

A static outbound IP pins egress for your deliveries to a fixed address, or a small fixed set, that belongs to your account rather than a shared pool. Requests leave from there regardless of which worker picked up the delivery.

Table: what a security team can work with, depending on how your delivery layer handles egress.

Egress model	What you can tell the firewall team	Practical result
Shared cloud NAT pool	”Somewhere in this region”	Rule is effectively any-source, or refused
Published provider ranges	Hundreds of prefixes, updated periodically	Accepted rarely, drifts out of date
Static outbound IP	One address, or a short list	A rule they can write once and audit later

The gain is neither performance nor, on its own, security. A named address lets the firewall conversation end: it fits in a change ticket, gets reviewed in one pass, and can be checked during an audit a year later.

There are two caveats. An address can still need to change (hardware is replaced, a provider reclaims a block, an incident forces a failover), so nobody can promise it will never move. Expect advance notice and a documented process instead. Second, a static address does not make the traffic trustworthy. The allowlisting section below covers why.

The request to send a security team

Most firewall change requests get bounced because they say “please allow our webhooks” and omit everything the reviewer needs. Send this instead. Fill in the angle brackets and paste it into the ticket.

Firewall change request — inbound HTTPS from a webhook delivery service

1.  Direction
    Inbound to <destination hostname>, initiated by our webhook delivery
    provider. No inbound connections back to us are required, and no
    outbound rule change is needed on your side.

2.  Source addresses
    <the static outbound addresses shown in the provider's dashboard —
    copy them verbatim; do not substitute a broader range>

3.  Destination host and path
    https://<hostname>/<path>

4.  Destination port and protocol
    TCP 443, HTTPS with TLS 1.2 or later. Plain HTTP is not used.

5.  Traffic pattern
    Short-lived POST requests, one per event, plus automatic retries with
    exponential backoff when a delivery fails. Expected steady-state
    volume: <events per day>. Bursts during backlog replay: <peak>.

6.  What data flows
    JSON event bodies forwarded from <source system>, for example
    <order / payment / ticket> events. Personal data categories included:
    <list, or "none">.

7.  Application-layer authentication
    Every request carries an HMAC signature header that the endpoint
    verifies before processing. The IP allowlist is a network control and
    is not the authentication mechanism.

8.  Data residency
    Delivery workers and stored event data are located in <region>.

9.  Change management
    We will notify <contact address> before the source addresses change.
    The endpoint must continue to verify signatures regardless of the
    source address the request arrives from.

Point 7 and the last line of point 9 stop a reviewer from concluding that the allowlist is now the security boundary and the endpoint can relax. EU reviewers tend to press hardest on point 8, and where your gateway stores and processes events is a separate answer from where it delivers from.

Allowlisting is not authentication

An IP allowlist answers one question: may this packet enter the network? It says nothing about whether the request came from you, whether the payload was tampered with, or whether it was replayed from a capture taken last week.

Source addresses are also weaker evidence than they look. Address-based rules can be defeated by spoofing at the network edge in some topologies, by a compromised host inside the allowed block, or by a proxy shared with someone else. And if the allowlisted address belongs to a multi-tenant service, “traffic from this IP” means, in the worst reading, “traffic from any customer of that service.”

The destination therefore keeps verifying the signature on every forwarded request, whatever the source address. We cover why an IP allowlist supplements signatures rather than replacing them in more depth elsewhere; in short, the two controls answer different questions. Don’t turn signature checks off because a firewall rule is in place, including for an afternoon during a migration.

Layering it properly

Treat the network rule as the outermost of three layers:

Static outbound IP. Controls who can reach the endpoint at all. Reduces exposure and satisfies the firewall policy.
Signature verification on the forwarded request. Controls whether the request is authentic. Webhooker offers outbound request signing on every plan, so the endpoint can confirm a delivery came from us and the body was not altered in transit.
Mutual TLS, where the destination supports it. Proves identity at the transport layer. Many enterprise endpoints terminate mTLS at their edge and ask partners for a client certificate. That is a capability of the destination, so confirm it with the team that owns the endpoint.

If one layer is misconfigured, the other two keep working.

Where the workers run matters as much as their address

Once a security team is engaged, the next question arrives in the same thread: where does this traffic originate, and where is event data stored between arrival and delivery? Under GDPR that question carries weight, because the payloads themselves are usually personal data. Webhooker runs delivery workers in the EU, with ingest, storage, and backups in the EU as well, and enforces retention limits. Those facts are commonly treated as a meaningful part of a transfer assessment, but they are not a legal guarantee on their own. You remain the controller, so check the arrangement with your DPO.

On Webhooker

Static outbound IP is a Team-plan feature. It is not available on Free or Pro, and there is no add-on for those plans. If a destination’s security team requires a fixed source address, you need the Team plan.

Outbound request signing is included on every plan, Free included, since the signature is what authenticates a forwarded request. A Free account is enough to route an event and check that signature on your own endpoint before the firewall change is requested.

Frequently asked questions

Can I get a dedicated outbound IP on the Pro plan?

No. Static outbound IP is on the Team plan only, and there is no add-on that attaches it to Free or Pro. If your destination requires a fixed source address, Team is the plan that provides it. The rest of the security stack does not depend on your plan: per-source signature verification on inbound events, and outbound signing on the requests we forward, are included everywhere, Free included.

What happens if the outbound IP has to change?

Assume it can. Addresses move when infrastructure is replaced, when a provider reclaims a block, or when an incident forces traffic down a different path. Expect notice before a planned change, and write that expectation into the original firewall request as in the template above. A change stays manageable because the endpoint authenticates requests by signature rather than by source address, so a new address means a firewall ticket and nothing worse.

Is an IP allowlist enough on its own?

No. An allowlist is a network control that decides which connections may enter. It does not verify that a request is authentic, unmodified, or fresh. Addresses can be spoofed in some topologies, shared through NAT, or inherited by a compromised host inside the allowed block. Keep verifying the HMAC signature on every forwarded request, and treat the allowlist as the layer that reduces exposure rather than the one that establishes trust.

Does this change anything on the inbound side?

No, these are separate directions. Static outbound IP concerns traffic leaving Webhooker toward your destinations. Inbound events arrive at an ingest URL you hand the provider, and there the provider is the party with published addresses: Stripe documents its webhook IPs, and GitHub exposes its ranges through the meta endpoint. Allowlisting those is optional; verifying each provider’s signature before the payload is accepted is not, and we do that per source.