e2a

The open-source email API for applications and AI agents.

Send transactional email and give agents real two-way inboxes, with people in control.

Try hosted e2a — start free →

We run the email infrastructure. You connect your app or agent.

Self-host with Docker · Documentation · Agent quickstart · Examples

A Token Canopy product · Apache 2.0

Using a coding agent? Paste this prompt into its chat:

Connect this coding agent to hosted e2a MCP at https://api.e2a.dev/mcp and help me sign in via browser OAuth.

Supports coding agents with remote MCP and browser OAuth. Client setup guide.

Choose how to start

• Hosted — recommended for getting started. Sign up at e2a.dev. Includes the shared agents.e2a.dev domain for instant slug-based onboarding (no DNS setup), a dashboard, the hosted MCP server, and managed deliverability.
• Self-host — run your own infrastructure. See Self-host (Docker) and Deployment. Nearly every feature works the same (content screening is currently self-host-only — see the note below); the shared-domain slug shortcut just needs you to point a mail domain at your relay and set shared_domain in config.yaml.

For application email, start with the transactional email guide. For coding agents, use the prompt above or the setup instructions below.

Quickstart

Connect your agent to hosted e2a

Give your AI agent an inbox directly. Install the e2a plugin — it registers the hosted MCP server and an operate-well skill, so your agent can send, receive, reply in-thread, and hold mail for review out of the box. On first tool use it runs an OAuth flow in your browser — no API key to paste.

Claude Code

claude plugin marketplace add tokencanopy/e2a
claude plugin install e2a@e2a

Codex

codex plugin marketplace add tokencanopy/e2a

Then launch codex, run /plugins, and install e2a.

Cursor — add the MCP server directly. Put this in .cursor/mcp.json (or ~/.cursor/mcp.json to get it in every project); Cursor opens your browser to authorize on first use, no API key to paste:

{
  "mcpServers": {
    "e2a": { "url": "https://api.e2a.dev/mcp" }
  }
}

Other MCP clients (Zed, Goose, Windsurf, Claude Desktop, raw mcp.json) — point straight at https://api.e2a.dev/mcp; ready-to-paste configs are in plugins/e2a/clients/. See plugins/e2a/README.md for the full per-client guide.

What e2a provides

e2a is the open-source email API for applications and AI agents. Any product can send transactional email over HTTP, TypeScript, or Python; agent-native systems can also use real two-way inboxes. Inbound mail arrives with structured SPF, DKIM, and DMARC evidence, and outbound mail can use an optional human-in-the-loop approval gate. Use the hosted service or run the Apache-2.0 stack yourself. No AI agent or agent framework is required for application-triggered sending.

Four ways to plug an agent in:

• MCP — point any MCP-aware runtime at the hosted server (https://api.e2a.dev/mcp) and your agent gets an inbox toolset (list_messages, send_message, reply_to_message, …). The fastest path for agent frameworks. → MCP server
• SDKs — TypeScript (@e2a/sdk) and Python (e2a) clients with one-call webhook verification and a WebSocket listen() stream. → SDKs
• Raw delivery — subscribe a webhook, open a WebSocket, or poll the REST API directly. → Delivery channels
• CLI — e2a listen bridges inbound mail to a local HTTP handler (including an OpenAI Responses auto-reply mode). → CLI

What you get on top of bare SMTP:

• Authenticated inbound identity — normalized SPF, DKIM, and DMARC evidence, with an explicit aligned DMARC verdict
• No public URL required — WebSocket, REST polling, and MCP all work from a laptop or behind a firewall
• Outbound API — agents send to other agents (SMTP relay) or humans (upstream SMTP, e.g. SES, Resend)
• Human in the loop — opt-in approval gate that holds outbound mail until a reviewer approves via dashboard, magic-link email, the MCP tools, or the API
• Inbound threat screening — opt-in content scan flags prompt-injection payloads (hidden HTML, Unicode-tag smuggling, encoded text) — and, with the LLM detector, phishing — then routes each message to allow · review · block, feeding the same review queue as HITL → Content screening. Available on self-hosted deployments; not yet enabled on the hosted service.
• Email reply topology — standards-compliant reply headers plus optional beta thread_id metadata on message reads; caller-owned conversation_id remains application correlation
• Email templates (beta) — reusable {{variable}} templates rendered server-side at send time, plus a pre-built starter catalog → docs/templates.md
• Contacts & outreach (beta) — account-level contact identity (CRUD + bulk import with safe reversal) and per-agent outreach state with server-derived reply/delivery facts, plus the contact.due due-queue notification event → docs/api.md
• Scheduled sending (beta) — send_at on send/reply/forward defers submission up to 90 days ahead; a scheduled send is durable acceptance (status=scheduled) and can be canceled by trashing the message before submission

What you can build

e2a is useful anywhere an AI agent needs a real inbox, persistent email threads, and a safe path from inbound message to outbound action. Start with a complete example:

• Build an AI support agent — triage customer requests, retrieve context, reply in-thread, and hold sensitive replies for approval.

• Build an AI receptionist — answer common inquiries, route messages, and forward conversations to a human team.

• Build an AI scheduling agent — coordinate participants, propose times, and preserve state across multi-turn replies.

• Build an e-commerce agent — answer order questions, handle returns, and coordinate with vendors through persistent email threads.

• Build a sales agent — qualify inbound interest, personalize follow-ups, and keep every conversation moving.

• Build a recruiting agent — coordinate candidates, schedule interviews, and keep hiring workflows in one thread.

• Build a voice follow-up agent — turn a completed call into an email follow-up and keep the conversation going.

• Build a procurement agent — coordinate quotes, purchase orders, and vendor threads with human approval for commitments.

• A support inbox for your AI assistant — give an agent support@yourbrand.com, receive customer mail with SPF/DKIM/DMARC already evaluated as structured evidence, and reply in-thread. Add HITL so anything sensitive waits for a human to approve before it goes out.

• Email between agents — yours and other organizations' — every agent has a real, verified address, so two companies' agents can exchange mail the same way humans do: no new client, protocol, or shared platform to install.

• A personal concierge on your laptop — subscribe over WebSocket (no public URL, no ngrok, no port forwarding), so a local agent can watch an inbox from behind any firewall, triage it, draft replies, and take actions.

• Email-triggered workflows — turn inbound mail into structured events: order confirmations, forms, support tickets, notifications, and receipts rendered server-side from templates, with conversation_id correlated back to your app's state.

• Autopilot with human oversight — an agent drafts outbound mail (newsletters, outreach, reports) and holds each send for one-click approval via magic-link email or the review queue, with automatic expiry policy if no one reviews in time.

Working examples

e2a-runbooks builds several of the above as small, complete, runnable projects — one per agent framework, each demonstrating a different use case and a different part of this API:

Example	Framework	What it shows
Support agent	Mastra	Threading, memory, and the outbound approval gate
Receptionist	OpenAI Agents SDK	forward to a desk allowlist, update_labels
AI SRE	Claude Agent SDK	Authentication as a gate; a no-tools agent that can't touch prod
Contract review	LangChain	Attachments — including the data-vs-download_url split
Escalation desk	CrewAI	Several agent identities; cross-identity conversation_id
Scheduling secretary	Pydantic AI	Multi-turn state rebuilt from conversations, no database

They are examples to copy from rather than services to deploy — each says what it simplifies. For the smallest possible signed-webhook reference instead, see the in-repo minimal examples.

How it works