Hooksbase

Channels / April 25, 2026

Email-to-webhook for AI agents (parse, route, deliver)

Email-to-webhook flow showing inbound mail parsed to JSON and delivered to an agent

Most AI agent triggers come from HTTP webhooks. But a huge slice of real-world signal arrives by email — support requests, transactional confirmations from systems without webhooks, vendor invoices, contract responses, customer feedback. If your agent can't react to inbound email, it's missing the trigger that drives a lot of useful work.

This guide covers what email-to-webhook actually means, how Hooksbase's email ingest works, and the agent use cases that depend on it.

What email-to-webhook does

Email-to-webhook converts an inbound email message into a structured JSON event delivered to your agent's HTTP endpoint. The flow:

  1. You give Hooksbase an email-ingest address for a webhook (e.g. hook_xyz123@ingest.hooksbase.com).
  2. You configure your domain to forward incoming mail to that address (or use it directly as a public address).
  3. When email arrives, Hooksbase parses it into JSON — subject, sender, recipient, plain-text body, HTML body, selected headers, attachments — and delivers the JSON to your destination.
  4. Your agent processes it like any other webhook event.

The agent's HTTP endpoint receives structured JSON instead of raw MIME. The payload shape still identifies the channel with source: "email" so your agent can branch when needed.

Why this matters more than it sounds

Receiving email programmatically without this layer means:

  • An MX record pointing somewhere you control
  • An SMTP server (or a third-party service like Postmark, SendGrid, or Mailgun) accepting the mail
  • A parser (postal-mime, mailparser, or similar) turning RFC-822 into structured fields
  • Attachment handling — extracting them from MIME parts, storing them somewhere, deciding the size limits
  • Sender filtering — an allowlist for who can actually trigger the agent
  • Rate limiting — open inboxes get spammed; you need throttling
  • A delivery layer — once parsed, the event still has to reach your agent reliably

Each of these is solvable. None of them are the agent. Building all of them yourself takes weeks; using a relay that handles them takes about ten minutes.

How Hooksbase email ingest works

Hooksbase parses incoming email with postal-mime, normalizes it to JSON, and delivers it to your destination as a regular webhook event. The parsed payload includes:

{
"source": "email",
"from": "customer@example.com",
"to": "hook_xyz123@ingest.hooksbase.com",
"subject": "Re: Issue with my account",
"text": "Hi there, ...",
"html": "<html>...</html>",
"attachments": [
  {
    "filename": "screenshot.png",
    "contentType": "image/png",
    "size": 142357,
    "fileRef": {
      "key": "files/...",
      "url": "https://hooks.hooksbase.com/v1/files/<signed>"
    }
  }
],
"messageId": "<...@mail.example.com>",
"date": "Sat, 25 Apr 2026 14:30:00 +0000",
"headers": {
  "reply-to": "customer@example.com"
}
}

Attachments are stored in R2 and referenced by signed URLs your agent can fetch on paid tiers (up to 15 MB per file, 50 MB per ingest). Free projects receive attachment metadata only, without fileRef.

Optional features worth knowing about:

  • Sender allowlist — restrict who can trigger the webhook by email address or domain on Starter+. Anyone outside the allowlist is silently dropped before delivery.
  • Routing rules — parse the subject or body and route to different downstream destinations based on content.
  • Payload transforms — flatten the parsed structure into the shape your agent expects (extract fields, drop noise).

Common email-to-webhook use cases for AI agents

The patterns that show up across teams:

  • Support triage agent — emails to support@your-app.com route to an agent that classifies the issue, looks up the customer, and either drafts a reply or escalates to a human.
  • Vendor invoice processor — invoices emailed to invoices@your-app.com trigger an agent that extracts the line items, matches the vendor, and submits to your accounting system.
  • Reply-to-engage agent — customers replying to a marketing email trigger an agent that interprets the reply (interested? unsubscribe? question?) and routes accordingly.
  • Form-by-email agent — vendors or customers submit structured information by email (the lowest-friction interface for non-technical users); an agent extracts the fields and processes them.
  • Receipts-to-CRM agent — purchase confirmations from systems without webhooks (older SaaS tools, internal tools) trigger an agent that parses the confirmation and updates the CRM.
  • Calendar response agent — meeting requests and responses trigger an agent that updates internal scheduling state and notifies the relevant team.

In every case, the email is the trigger; the agent is the action; the relay layer is the durable plumbing that makes the whole thing reliable.

Why this is harder than HTTP

Email arrives more slowly and less predictably than HTTP webhooks. Two specific challenges:

1. Latency. Even with direct SMTP delivery, email transit times vary from seconds to minutes. Your agent has to be tolerant of "user sent this 5 minutes ago" rather than "this happened just now."

2. Spam and abuse. Open email addresses get hit immediately. Sender allowlists and project rate limits are load-bearing. Hooksbase's email ingest supports both, with sender allowlists available on Starter+.

These don't make email a bad trigger source. They mean designing the agent for the channel: don't expect synchronous response, do build in the abuse mitigation.

Where to go next

Start free at app.hooksbase.com.

Related guides

Back to guides