MultiMail emits structured webhook payloads for every stage of the email lifecycle — sent, delivered, bounced, inbound reply, complaint — so your agent can act the moment something changes.
AI agents that send email are flying blind without a reliable event stream. A message can bounce silently, a reply can sit unread for hours, or a complaint can go undetected until deliverability craters. Polling the inbox is slow, noisy, and misses transient events like delivery confirmations and bounce codes entirely. Without a real-time signal, agents cannot trigger retry logic, route replies to the right workflow, or escalate failures before they compound.
MultiMail emits a webhook for every material email event: message.sent, message.delivered, message.bounced (soft and hard), message.received (inbound), and message.complained. Each payload is signed with an HMAC-SHA256 signature so your endpoint can verify authenticity before processing. Each delivery is wrapped as { event, timestamp, data }, and the data object carries the mailbox_id, the email_id, and event-specific fields (SMTP diagnostic codes on bounces) — enough for your agent to branch without a follow-up API call. You subscribe per mailbox (or account-wide), and MultiMail fans events out to your endpoint.
POST to /v1/webhooks with your endpoint URL and the event types you care about (message.received, message.sent, message.delivered, message.bounced, message.complained; oversight.pending/approved/rejected are also available). Creation requires operator approval. MultiMail returns the subscription id and a signing secret you store securely.
When an event fires, MultiMail POSTs a JSON payload shaped as { event, timestamp, data }. The data object includes mailbox_id and email_id, plus event-specific fields (e.g., bounce_code, diagnostic, and recipient on bounce events; from and subject on inbound events).
Each request carries an X-MultiMail-Signature header formatted as sha256=<hexdigest> — an HMAC-SHA256 of the raw request body using your signing secret. Recompute it (with the sha256= prefix) and reject any request where the signature does not match before executing downstream logic.
Branch on the payload's event field. A message.received event triggers read_email (using the data's email_id) to fetch the full message. A hard bounce triggers your suppression and retry logic. A complaint triggers immediate opt-out handling.
After processing, your agent calls set_tags or updates its own state store to mark the email as handled. This prevents duplicate processing if a retry delivers the same event.
Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.
Webhooks push events to your endpoint the moment they occur. Your agent does not burn API quota or introduce latency by polling check_inbox on a timer.
Every event carries the mailbox_id, the email_id, and event-specific diagnostics in its data object. A bounce event carries the SMTP bounce_code, diagnostic, and recipient. An inbound event carries from and subject. Read the email by id when you need the full body.
Each webhook delivery is signed with HMAC-SHA256. Your endpoint can cryptographically verify that the payload originated from MultiMail before executing any downstream logic.
message.sent, message.delivered, message.bounced (soft and hard), message.received, and message.complained events are all emitted — plus oversight.pending/approved/rejected for the approval lifecycle. Agents can build complete state machines over email threads without gaps.
If your endpoint returns a non-2xx response or times out, MultiMail retries the delivery with exponential backoff (up to 3 attempts) before marking it failed. Build idempotent handlers so a retried delivery is safe to process twice.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.