Static Outbound IPs for Webhooks: Firewall 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 allow that one address instead of a whole cloud region. It solves a delivery problem, not a trust problem. An allowlist tells a firewall which connections may pass; it says nothing about whether a request is genuine. Signature verification is still the thing that answers that.

This comes up in one situation almost exclusively: your customer’s security team owns the endpoint you deliver to, and their default posture is deny. Nothing about your retry policy matters until the packet is allowed through the door.

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: traffic from a named set of source addresses is accepted, 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, not technical: 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. Which brings up the first real problem.

Why shared cloud egress breaks allowlisting

If your delivery workers run on a normal cloud setup, you cannot honestly tell anyone 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 still — the egress address can differ between two invocations a second apart. None of this is broken; it is what elasticity costs.

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 quietly turned a specific rule into a broad one, which is 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 actually work with, depending on how your delivery layer handles egress.

The value is not performance, and not security on its own. It is that the conversation becomes finishable. A named address fits in a change ticket, gets reviewed in one pass, and can be pointed at during an audit a year later.

Two honest caveats. An address can still need to change — hardware is replaced, a provider reclaims a block, an incident forces a failover — so anyone promising an address that will never move is describing a wish. Expect advance notice and a documented process instead. And a static address does not make the traffic trustworthy, which is the next section and the one that matters most.

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 are there deliberately. They stop a reviewer from concluding that the allowlist is now the security boundary and the endpoint can relax. Point 8 is the one EU reviewers press hardest on, 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.”

So the rule does not bend: the destination keeps verifying the signature on every forwarded request, whatever the source address. We go deeper into why an IP allowlist supplements signatures rather than replacing them elsewhere; the summary is that the two controls answer different questions. Never turn signature checks off because a firewall rule is in place — not permanently, and not 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.

Each layer still does its job when another is misconfigured. That is the entire point.

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 is not a footnote, because the payloads themselves are usually personal data. Webhooker runs EU-only delivery workers, with ingest, storage, and backups in the EU as well, and enforces retention limits — commonly treated as a meaningful part of a transfer assessment. It is not a legal guarantee on its 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 on Free or Pro, and we would rather say that plainly than have you find out after a procurement call. If your buyer’s security team requires a fixed source address, that requirement puts you on static outbound IP on the Team plan.

Outbound request signing is on every plan including Free, because the signature and not the address is what makes a forwarded request trustworthy. You can route your first event and verify that signature on your own endpoint before the firewall conversation starts.

Frequently asked questions