Reference
Endpoint Verification & URL Requirements
An Endpoint doesn't start receiving real traffic the instant you create it — it has to prove it's actually reachable and under your subscriber's control first.
URL requirements, checked at creation time
HTTPS only
Plain
http:// endpoints are rejected outright — there's no exception for "just testing," even in development, since signing secrets and payloads shouldn't travel in plaintext.No private, loopback, or link-local addresses (SSRF protection)
The URL's resolved IP is checked against a blocklist before it's accepted — this stops an Endpoint from being pointed at your own internal infrastructure or your cloud provider's metadata service.
| Range | What it covers |
|---|---|
| 0.0.0.0/8 | Unspecified — host wildcard |
| 127.0.0.0/8 | IPv4 loopback |
| 10.0.0.0/8 | RFC 1918 private (class A) |
| 172.16.0.0/12 | RFC 1918 private (class B) |
| 192.168.0.0/16 | RFC 1918 private (class C) |
| 169.254.0.0/16 | Link-local — includes the AWS/GCP/Azure metadata service at 169.254.169.254 |
| ::1/128 | IPv6 loopback |
| fc00::/7 | IPv6 unique local |
Testing locally? Use a public tunneling/inspection service (e.g. webhook.site, or your own
ngrok-style tunnel) instead of pointing at
localhost — a loopback address will always
be rejected, by design.
Challenge-response verification
After the URL passes the checks above, the Endpoint sits in unverified status until it responds correctly to a one-time challenge.
Endpoint created
→
GET {url}?webhook_challenge={token}
→
must return 200 + echo the token
→
status: active
What "echo the token" means
Your server receives a GET request with
?webhook_challenge=<random_token> in the query string. Respond 200 OK with that same token somewhere in the response body — that's the entire contract.5-second timeout
If your server doesn't respond within 5 seconds, doesn't return 200, or the echoed token doesn't match, the Endpoint stays
unverified — it is not retried automatically. Fix whatever's wrong, then re-trigger verification from the dashboard.Re-verification on URL change
Editing an Endpoint's URL resets it back to
unverified and re-runs the same challenge — an Endpoint is only ever "verified" for the exact URL it currently points to.
An unverified Endpoint still receives no deliveries even if it has Subscriptions —
verification isn't optional paperwork, it's a hard gate before any real event reaches it.