Ingest channel
Turn inbound email into a webhook your agent can act on.
Email-to-webhook converts an inbound email into structured JSON delivered to your endpoint: every Hooksbase webhook gets a permanent address like hook_xyz@ingest.hooksbase.com, and mail sent to it is parsed into sender, subject, body, headers, and attachments, then delivered with the same retries, signing, replay, and dead-letter handling as any HTTP event.
A large share of real business signal never arrives over HTTP. Support requests, vendor invoices, contract responses, and confirmations from older systems arrive by email. An agent that cannot read a mailbox is cut off from most of that work.
Email ingest is available on every plan, including Free. Writing sender-allowlist entries requires Starter or above. Attachment files are persisted on paid plans; Free receives attachment metadata only.
How it works
Creating a webhook returns an emailIngestAddress of the form hook_xyz@ingest.hooksbase.com. It is stable for the lifetime of the webhook. The address itself is the access credential, so rotate the webhook if it leaks.
Use the address directly as a public inbox, or forward to it from a domain you already own. There is no MX record to configure on your side and no public HTTP route for email ingest — the producer simply sends mail.
Hooksbase parses the message into JSON with source set to email, plus from, to, subject, text, html, selected headers, messageId, date, and an attachments array. Your agent reads fields instead of RFC-822 MIME.
Routing rules can match on the parsed payload — subject line, sender, any field — and select the destination. Automations can reshape the payload before your agent sees it. Then it delivers with retries and lands in delivery history.
Email to webhook at a glance
| Address shape | hook_xyz@ingest.hooksbase.com, one per webhook, permanent |
|---|---|
| Parsed fields | source, from, to, subject, text, html, headers, messageId, date, attachments |
| Attachment limits | 15 MB per file, 50 MB per ingest, on paid plans |
| Attachment access | Signed download URL, plus an authenticated retrieval route |
| Sender allowlist | Exact address, *@domain, or local-part@* patterns |
| Outbound destinations | HTTP, and on Pro or above AWS SQS, EventBridge, GCP Pub/Sub, and S3-compatible storage |
Email to webhook is not a side door.
Every channel lands in the same delivery engine. The same routing rules, Automations, retry policy, Standard Webhooks-compatible signing, delivery history, analytics, deterministic replay, and dead-letter handling apply no matter how the event arrived.
- • An MX record and an SMTP receiver
- • A MIME parser turning RFC-822 into usable fields
- • Attachment extraction, storage, and size limits
- • Sender filtering so an open inbox is not a liability
- • Rate limiting for a publicly reachable address
- • A delivery layer with retries, replay, and a dead-letter path once the mail is parsed
Inbound-email services and email parsers solve the parsing half: they accept the mail and hand you a POST with parsed fields. What they hand off is a single HTTP request. If your endpoint is down, if the agent times out, or if you need to re-run that message next week against the config that was live at the time, that is yours to build. Hooksbase parses the mail and then keeps the event — retries, signing, delivery history, replay, and a dead-letter path included.
What teams use it for
Mail forwarded from a support address triggers an agent that classifies the request, looks up the customer, and either drafts a reply or escalates.
Invoices emailed to a dedicated address trigger an agent that extracts line items and vendor, then submits to your accounting system. Attachments come through as fetchable files.
Plenty of internal and older tools can send email and nothing else. Email ingest turns their notifications into structured events without asking the vendor for an API.
A customer replying to an outbound message triggers an agent that interprets the reply and routes it, rather than leaving it in a shared inbox.
Limits worth knowing before you build on it
Every channel has edges. These are the ones that change how you design around it.
Until you add allowlist entries, any sender who knows the address is accepted. That is deliberate — it makes the address usable immediately — but treat it as a public endpoint and add an allowlist before production. Allowlist writes need Starter or above.
Transit time varies from seconds to minutes. Design the agent for "this was sent a few minutes ago", not "this just happened". Do not build synchronous request-response expectations on the email channel.
Archived or missing webhooks reject as an unknown recipient. Paused webhooks accept at the SMTP layer and skip. Disabled projects and blocked senders drop silently rather than bouncing, to avoid bounce loops. Check delivery history rather than expecting a bounce.
Frequently asked questions
- How do I convert email to a webhook?
- Create a Hooksbase webhook and use the emailIngestAddress it returns. Any mail sent to that address is parsed into JSON and delivered to the webhook destination as a normal event, with retries, signing, and replay. There is nothing to configure on the receiving side.
- Do I need to own a mail server or set up MX records?
- No. Hooksbase hosts the receiving address. You either use the generated address directly or forward mail to it from a domain you already control.
- What does my agent actually receive?
- Structured JSON with source set to email, plus from, to, subject, plain-text and HTML bodies, selected headers, messageId, date, and an attachments array. Your agent reads fields rather than parsing MIME.
- Are attachments included?
- Yes on paid plans, up to 15 MB per file and 50 MB per ingest. Each attachment carries a signed download URL, and an authenticated retrieval route is also available. Free projects receive attachment metadata without the file reference.
- Can I restrict who is allowed to send?
- Yes, with a per-webhook sender allowlist supporting exact addresses, domain wildcards such as *@example.com, and local-part wildcards such as alerts@*. Creating allowlist entries requires Starter or above. An empty allowlist accepts any sender.
- Can an email end up somewhere other than an HTTP endpoint?
- Yes. Email-sourced events use the same typed destinations as every other channel, so an inbound message can be delivered to AWS SQS, EventBridge, GCP Pub/Sub, or S3-compatible storage. Non-HTTP destinations require Pro or above.
- Can I replay an email-triggered event?
- Yes. Email deliveries are stored as dispatch snapshots like any other delivery, so they can be replayed individually or in bulk, and they re-run against the configuration captured at the time rather than the current one.
Try it on the free plan
5,000 deliveries a month, no card. Create a webhook and the email channel is available on it immediately.