What is an IP allowlist?

An IP allowlist restricts which source addresses may reach a webhook endpoint, typically by admitting only the IP ranges the provider publishes for its sending infrastructure. It answers a firewall's question, "may this address connect?", not an authentication question, and that distinction decides both what it is good for and why it cannot replace signature verification.

Sending webhooks?

Svix is the enterprise-ready webhook sending service. It handles signing, retries, and delivery observability, so you can ship a reliable webhook platform in minutes instead of months. Start sending webhooks with Svix.

Why allowlists exist for webhooks

Plenty of receivers sit behind corporate firewalls, VPNs, or private networks that default-deny inbound traffic. For a webhook to arrive at all, the provider's senders must be let through, which is why providers such as Svix publish a fixed set of source IPs and keep them stable: the consumer's network team opens those addresses and delivery works.

Used this way, the allowlist is an availability mechanism with a security bonus. It also cheaply discards internet background noise, port scans and random POSTs from arbitrary hosts, before any of it reaches the application, which quiets logs and shrinks the surface exposed to unauthenticated traffic.

Why an allowlist is not authentication

Relying on the allowlist alone, with no signature check behind it, fails in several distinct ways.

• Shared and recycled addresses. Cloud senders often share egress IPs across many tenants, and released addresses get reassigned. "Traffic from this IP" does not mean "traffic from this provider," and it certainly does not mean "traffic on behalf of my account."
• Same-provider tenants. Every customer of the same webhook platform sends from the same IPs. An allowlist admits all of them equally, so another tenant can aim requests at your endpoint from an address you trust.
• Nothing about content. An allowlist says where a packet came from, not that its body is intact, fresh, or unreplayed. Integrity, replay protection, and origin proof are what the signature and timestamp tolerance checks provide.
• Operational fragility. Providers occasionally must change ranges; a hard dependency on the list turns that into an outage.

This is the reasoning behind the standard guidance, Svix's included: the allowlist is welcome as an outer layer, and the signature check remains mandatory behind it. The Standard Webhooks specification's security model is built on signatures for exactly this reason; source addresses appear nowhere in it.

Using one well

Treat the published ranges as configuration with a lifecycle rather than a one-time firewall edit. Take them from the provider's documentation or API, prefer an automated sync where volumes justify it, and subscribe to whatever channel the provider uses to announce changes. Enforce at the network edge, keep the application-layer verification unchanged, and make the failure mode observable: when deliveries stop while the provider reports success, a stale allowlist is one of the first things to check.

For where this layer sits among the others, see webhook security and the security best practices.

Frequently asked questions

Is an IP allowlist enough to secure a webhook endpoint?

No. Cloud sender IPs are shared across tenants and can be recycled, and an address check proves nothing about a payload's integrity or freshness. Use the allowlist as an outer filter and verify the signature on every request behind it.

Why do webhook providers publish static source IPs?

So consumers behind default-deny firewalls can receive deliveries at all. A stable published range lets network teams open exactly the necessary addresses, which is primarily an availability feature rather than a security one.

What happens when a provider changes its sending IPs?

Receivers still enforcing the old list silently drop the new traffic while the provider sees connection failures and retries. Providers announce changes ahead of time; syncing the list automatically or subscribing to those announcements prevents the outage.

Should I combine an IP allowlist with signature verification?

Yes, that is the intended pairing. The allowlist cheaply discards traffic that could never be legitimate, and the signature proves origin and integrity for everything that remains. Neither substitutes for the other.