Email Inboxes

Every webhook endpoint can receive email. Turn the inbox on and <subdomain>@otterkit.app starts accepting mail - each message lands in the endpoint's feed as a capture with method EMAIL, right next to the HTTP traffic. The body is a JSON envelope (from, to, subject, text, html, attachment metadata), so forwarding rules, notifications, stored history, and replay all treat an email like any other request.

$ npx otterkit webhook --email
  Webhook ready: https://hook-e5f6g7h8.otterkit.app
  Inbox    [email protected] - mail lands in the feed like a request

In the console, the endpoint header shows the inbox address with an on/off switch, and the Email tab is a proper reader: message list on the left, the rendered email (HTML or text) on the right, with headers and attachment details. Search covers subject and sender across everything stored.

For agents

Agents constantly need to receive email - signup confirmations, OTPs, magic links. Create the endpoint with webhook_create and email: true over MCP, hand the address to whatever service needs it, then request_await catches the message the moment it arrives - same tool that awaits webhooks:

webhook_create { "subdomain": "signup-test", "email": true }
→ [email protected]

request_await { "subdomain": "signup-test", "method": "EMAIL" }
→ { "subject": "Your verification code", "text": "Code: 481-923", ... }

Bounce semantics

Nothing is silently dropped. Mail to an endpoint whose inbox is off, an expired or stopped endpoint, or an address that doesn't exist is rejected at SMTP time, so the sender gets a normal bounce with the reason. Received emails count toward the endpoint's fair-use request limit; the stored envelope is capped at 64 KB (long bodies are truncated, HTML first) and attachment contents are not stored - only names, types, and sizes.