IP Allowlists

IP allowlists restrict which source IP addresses can send requests to a webhook endpoint. Only matching IPs are accepted; all others are rejected with 403 Forbidden.

How IP allowlists work

When an endpoint has IP addresses configured on its allowlist, every inbound request is checked before authentication, validation, or delivery. If the originating IP does not match any entry, the request is immediately rejected:

• HTTP response: 403 Forbidden
• Activity outcome: IP_BLOCKED
• The request does not consume monthly quota

IP filtering applies only to enabled endpoints. Disabled endpoints return 404 for all requests regardless of source IP. PayloadRelay resolves the client IP from the direct connection in development and from Cloudflare's CF-Connecting-IP header only when the immediate peer is a trusted Cloudflare/loopback proxy, so spoofed X-Forwarded-For headers do not bypass allowlists.

Prerequisites and permissions

• Endpoint edit access.
• Webhook endpoint type (IP allowlists are not available on email ingestion endpoints).

Step-by-step workflow

1. Open the endpoint security settings

1. Open the endpoint in the Endpoints page.
2. Navigate to the Security tab.
3. Scroll to the IP allowlist section.

2. Add allowed IP addresses

Click Add IP and enter an IP address or CIDR block:

Format	Example	Matches
Single IPv4	203.0.113.5	Exactly that one address
IPv4 CIDR	198.51.100.0/24	All addresses in the 198.51.100.0–255 range
Single IPv6	2001:db8::1	Exactly that one address
IPv6 CIDR	2001:db8::/32	All addresses in the 2001:db8 prefix

3. Configure IP version (optional)

If your senders use only IPv4 or only IPv6, you can restrict the allowed IP version:

Version filter	Effect
Any (default)	Accept both IPv4 and IPv6 from allowlisted addresses
IPv4 only	Reject all IPv6 requests regardless of allowlist
IPv6 only	Reject all IPv4 requests regardless of allowlist

4. Save and verify

1. Save the endpoint.
2. Test by sending a request from an allowed IP — it should succeed (ACCEPTED).
3. Test by sending a request from a non-allowed IP — it should fail with IP_BLOCKED in Activity.

Allowlist behavior

Scenario	Result
Allowlist is empty (default)	All IPs are accepted
Request IP matches an entry	Request proceeds to auth/validation
Request IP does not match any entry	403 Forbidden, logged as IP_BLOCKED
Endpoint is disabled	404 for all IPs (allowlist check is skipped)

Common use cases

• Server-to-server integrations: Lock an endpoint to your application server's static IP so no one else can discover and abuse the relay URL.
• CI/CD pipelines: Allow only GitHub Actions or Jenkins runner IPs to trigger deployment endpoints.
• Compliance requirements: Restrict data ingestion to known corporate network ranges.

Monitoring blocked requests

In Request activity, filter by outcome IP_BLOCKED to see all rejected requests. Review the source IP column to identify legitimate senders that need to be added to the allowlist.

Common issues and fixes

• My requests are being blocked: Check that your public IP (not your internal LAN IP) is in the allowlist. Use a service like curl ifconfig.me to find your external IP.
• CIDR not matching: Verify the CIDR notation is correct. 192.168.1.0/24 covers .0 through .255; /32 is a single address. Use a CIDR calculator if unsure.
• IPv6 senders blocked: Either add the IPv6 address/CIDR to the allowlist or set the IP version filter to Any instead of IPv4 only.

Related guides

• Endpoint Management — full endpoint configuration reference.
• Authentication and Secrets — additional inbound security controls (basic auth, bearer tokens, API keys).
• HMAC Inbound Verification — verify webhook signatures from providers like GitHub, Shopify, Stripe.
• Observability — monitor IP_BLOCKED outcomes in the Activity log.
• Troubleshooting Ingest — diagnose common inbound errors.