What is a sender allowlist?
A sender allowlist is a per-webhook list of patterns controlling which senders may trigger email ingest. It is the access control on an otherwise publicly reachable address.
Supported patterns
- Exact address —
vendor@stripe.com - Domain wildcard —
*@example.com, or the bare formexample.com - Local-part wildcard —
alerts@*
Duplicate patterns are rejected. Listing entries works with any project key; creating or deleting them requires Starter or above.
Open by default
This is the important part. An empty allowlist means open ingest — any sender who knows the address is accepted. That makes the channel usable the moment a webhook is created, but it means the generated address should be treated as a public endpoint. Add allowlist entries before putting the channel in front of anything that matters.
Rejections are silent
Blocked senders are dropped rather than bounced, and disabled projects are dropped too. This is deliberate: bouncing to a forged sender creates backscatter, and bouncing to a real one creates loops. The consequence for operators is that a blocked message produces no bounce notification, so check delivery history rather than waiting for a rejection email.
Related failure modes on the same channel: archived or missing webhooks reject as an unknown recipient, and paused webhooks accept at the SMTP layer then skip without creating a delivery.
Frequently asked questions
What pattern forms does a sender allowlist accept?
An exact address such as vendor@stripe.com, a domain wildcard written either as *@example.com or as the bare example.com, and a local-part wildcard such as alerts@*. Duplicate patterns are rejected.
What happens to a sender that is not on the allowlist?
The message is dropped silently rather than bounced, and messages to disabled projects are dropped too. Bouncing to a forged sender creates backscatter and bouncing to a real one creates loops, so check delivery history rather than waiting for a rejection email.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
Related terms
- Email ingest
Accepting an inbound email as an event by sending it to a webhook’s generated ingest address.
Read - Ingest channel
One of the four ways an event enters Hooksbase: HTTP, email, form, or scheduled cron.
Read - Ingest
Accepting an event into Hooksbase via HTTP, email, form, or scheduled cron.
Read - Standard Webhooks
An open spec for webhook signing headers that several modern providers (and Hooksbase) follow.
Read