# brevo webhook event delivery failed ip not whitelisted

## TL;DR
Your ingress rules are dropping Brevo's delivery attempts. Find Brevo's published webhook sending IP ranges, add them to your firewall, security group, or WAF allowlist, and confirm the endpoint is reachable from those IPs. Trigger a test event from Brevo and watch it deliver with a 2xx.

```text
brevo webhook event delivery failed ip not whitelisted
```

## Use this when

- Brevo webhook logs show delivery failures while the endpoint works in a browser
- Events stopped arriving after a firewall or WAF change
- The failure mentions IP allowlisting or blocked requests

## Not for this skill when

- Webhook signature verification failures (key problem, not network)
- Brevo API calls failing (separate from webhook delivery)
- The endpoint returning 500 on delivery (your handler bug)

## Steps

### Step 1: Get Brevo's sending IPs

Look up Brevo's published webhook sending IP ranges in their documentation. Expected: a concrete list of IPs or CIDR ranges.

### Step 2: Allowlist the ranges

Add those ranges to your firewall, cloud security group, or WAF allowlist for the webhook path. Expected: the rules explicitly permit Brevo's senders.

### Step 3: Verify reachability

Confirm the endpoint responds over HTTPS without bot challenges or geo-blocking for those IPs. Expected: a clean 200 on a test request path.

### Step 4: Trigger a test event

Send a test webhook from Brevo's dashboard or trigger a real event. Expected: Brevo's webhook log shows a 2xx delivery.

### Step 5: Monitor delivery health

Watch Brevo's webhook logs for a day to confirm consistent delivery. Expected: failure rate drops to zero and stays there.

## Tool compatibility

Brevo (Sendinblue) webhooks; firewalls, cloud security groups, and WAFs; Brevo webhook delivery logs.

## Variant phrasings

### Variant 1

brevo webhook delivery failed blocked

### Variant 2

brevo webhooks not arriving firewall

### Variant 3

brevo sending ips allowlist webhook endpoint

## Why it happens

Webhook delivery is just an HTTPS POST from the provider's servers to yours, and any ingress control, firewall rules, WAF bot protection, or Cloudflare challenges, can silently eat it. The provider reports a delivery failure while your application logs show nothing, because the request never reached your code. Teams usually discover this after a security tightening that nobody connected to the webhook integration. The fix is allowlisting the provider's sending IPs, but the deeper lesson is that webhook endpoints are production infrastructure: they need the same change-management awareness as any other ingress rule.

## Edge cases / pitfalls

- WAF bot rules often score provider webhooks as bots; allowlist by IP rather than disabling the rule.
- Cloudflare's bot fight mode challenges automated POSTs; bypass it for the webhook path by IP.
- Brevo can change sending IPs over time; subscribe to their changelog or re-check periodically.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vCJqkrUyorABRjRguvesVA