Email for AI agents

Every address already exists

There is no inbox object here, so there is nothing to create and nothing to run out of. The moment a project exists it receives on a catch-all domain, and anything before the @ arrives.

That is what makes an address per agent, per ticket or per run practical: no provisioning call that can fail halfway, no registry to keep in sync, nothing to clean up when an agent is retired. Point an MX record at us and your own domain behaves the same way.

[email protected]
[email protected]
[email protected]

# all three receive right now — you did not create any of them

Answer in the thread, not beside it

Replying is its own endpoint rather than a send you assemble by hand. In-Reply-To, References and the Re: prefix are set from the message being answered, which is what puts your reply in the conversation the sender already has open instead of starting a second one next to it.

The reply goes out from a sending address you own — inbound domains are not verified for sending, so mail from one would fail SPF and DKIM — with Reply-To pointed back at the mailbox. Their next message comes back where the agent is looking, and the loop closes with nothing to configure.

curl -X POST https://emailbump.com/api/v1/inbound/MESSAGE_ID/reply \
  -H "Authorization: Bearer $EMAILBUMP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "text": "Sorry about that — it ships tomorrow." }'

Told, rather than polling

A webhook needs a public URL, which means a server and a deployment — the wrong shape for an agent that is already running and just wants to be notified. Open a WebSocket instead and messages are pushed as they land.

The frame is a summary: the id, who wrote in, and which of your addresses they wrote to. That last one is what makes an address per task work — an agent can tell at a glance whether the message is one of its own before fetching anything. Both routes are on at once, so a webhook to your backend and a socket to your agent can coexist.

const ws = new WebSocket("wss://emailbump.com/api/v1/inbound/stream", {
  headers: { Authorization: `Bearer ${process.env.EMAILBUMP_API_KEY}` },
})

ws.addEventListener("message", (e) => {
  const { type, email } = JSON.parse(e.data)
  if (type === "email.received") console.log(email.to, "←", email.from)
})

Built to be driven by something that isn't a person

Sign-up is an API call: post an address, read the six-character code out of the email we send, and you have keys. No browser, no password, no dashboard step in the middle of an automated setup.

From there an agent can use the REST API directly, the CLI, or the MCP server — 58 tools covering sending, receiving, audiences and provisioning, with the destructive ones gated behind explicit confirmation. There is a set of open SKILL.md files too, so an agent can be taught the sequence rather than shown a reference.

emailbump signup --email [email protected] --accept-terms
emailbump verify-email --email [email protected] 9MT89W
emailbump inbound:list --search "order"
emailbump inbound:reply MESSAGE_ID --text "On its way."

The part that isn't the mailbox

An agent answering mail eventually needs to know who it is talking to: whether they have been emailed before, what they were sent, whether they ever unsubscribed. That is the same product here rather than an integration — the address that received the message belongs to a project that also holds contacts, lists, segments and suppression state.

So when the job grows from answering to following up, it is a flow rather than another vendor. And every reply an agent sends is logged next to every campaign that person has ever had, which is the difference between a mailbox and a record.

What you can build with it

• An address per agent, per customer or per ticket, with nothing to provision
• Mail pushed to a running agent over a socket, with no URL to host
• Support mail read, threaded and answered without a human in the loop
• Sign-ups and verification codes an agent can receive and act on
• Received mail forwarded to a person, or auto-forwarded by a standing rule
• Replies logged beside every other email that contact has had