Receive on any address
Every local part on the project’s inbound domain works immediately. Use one address per agent, customer, ticket, or run without creating inbox objects.
Email API for AI agents
Give your agent
an email address.
Receive, read, reply, forward, and send through one API. No Gmail OAuth, no inbox provisioning, and no polling loop—just an address your software owns.
View as Markdown LIVE MAILBOX[email protected]
email.received14:20:04
policy.reviewed14:20:05
reply.accepted14:20:07
01ADDRESSCatch-all by project
02ARRIVALWebhook or WebSocket
03MESSAGEBodies + attachments
04ACTIONReply or forward
MAILBOX, NOT A MOCKOne inbound domain.
One inbound domain.
Unlimited useful addresses.
Each project gets a catch-all inbound domain. There is no inbox object to create: support@, agent-42@, and invoice-918@already work. Choose an address scheme that matches your application state.
The address routes the message; it does not grant authority. Your application still resolves which agent owns the conversation, which tools it may use, and which external actions require a person to approve them.
Read the email inbox API guideCOMPLETE CONVERSATION SURFACE
Receiving is only useful when the next step is safe.
The API carries the message identity and context an agent needs without turning every incoming sentence into an instruction.
React without polling
Use a signed email.received webhook for a backend or a WebSocket stream for a long-running agent. Fetch the full message only when it matters.
Read the real message
Retrieve text and HTML bodies, participants, raw threading headers, authentication results, spam verdicts, and the attachment list over API.
Reply in the same thread
Reply against the inbound message ID. Email Bump sets In-Reply-To, References, Reply-To, and the subject so the conversation stays together.
Handle attachments deliberately
Inspect metadata before downloading bytes. Keep untrusted files outside privileged execution and hand only the required content to the agent.
Escalate to a person
Forward one message or create a standing rule. The original formatting and attachments survive, and Reply-To points back to the sender.
EVENT-DRIVEN BY DEFAULT
From arrival to a threaded reply.
Push a summary first, fetch sensitive content only when required, and keep every consequential action behind application policy.
signed email.received event
policy, tools, and approval
threaded reply from verified domain
ONE CALL PER ACTIONRead the message.
Read the message.
Reply to its ID.
The reply endpoint derives conversation headers from the message you are answering. Your agent supplies the response, not a hand-built MIME thread.
- Original Message-ID preserved as conversation evidence
- In-Reply-To and References assembled automatically
- Reply-To sends the next response back into the workflow
agent-mailbox.sh
# Find messages waiting for the agent
curl 'https://emailbump.com/api/v1/inbound?limit=10' \
-H "Authorization: Bearer $EMAILBUMP_API_KEY"
# Read the selected message
curl 'https://emailbump.com/api/v1/inbound/MESSAGE_ID' \
-H "Authorization: Bearer $EMAILBUMP_API_KEY"
# Reply in the original conversation
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": "It ships tomorrow." }'BUILT FOR WORK, NOT INBOX THEATER
A mailbox per job, not another seat.
Use addresses as durable routing primitives for conversations your software is actually responsible for.
Support agent
Give each queue or customer a stable address. Classify, draft, answer, or route the conversation to a human.
Confirmation reader
Let an agent sign up for a service, receive the confirmation message, and return the code to the authorized workflow.
Invoice intake
Receive invoices and statements at task-specific addresses, inspect attachments, extract approved fields, and retain the original.
Workflow mailbox
Turn replies, documents, approvals, and exception messages into durable events for your application.
PROMPT-INJECTION-AWAREAuthenticated sender.
Authenticated sender.
Untrusted instructions.
Treat email bodies and attachments as user-controlled data, never system instructions.
Use SPF, DKIM, DMARC, spam, and virus results as identity and risk signals—not permission.
Give the agent narrow tools and scope each credential to the project it actually needs.
Require a human confirmation before forwarding sensitive data or sending consequential replies.
Record message IDs, decisions, tool calls, and outbound outcomes for later review.
MORE THAN HTTP
Use the surface your agent already speaks.
Every operation is available as a direct API. The CLI, MCP server, and open agent skills put safer workflows around the same account.
QUESTIONS, ANSWERED
Email API for AI agents FAQ
What is an email API for AI agents?+
It is a programmatic surface that lets an agent receive, inspect, send, reply to, or route email without operating a traditional mail client. A useful agent API exposes message identity, threading, attachments, delivery events, and constrained actions—not only a generic send call.
Does every agent need a separate inbox?+
No. Email Bump gives a project a catch-all inbound domain, so every local part already receives. You can assign addresses per agent or task without provisioning mailbox records, while application state remains the source of authorization and ownership.
Can an AI agent reply to received email?+
Yes. Reply using the received message ID and a verified sending identity. Email Bump preserves the thread headers and points Reply-To back to the inbound address so the next response returns to the same workflow.
Is an authenticated email safe for an agent to follow?+
No. SPF, DKIM, and DMARC help establish which domain sent a message; they do not make the message’s instructions trustworthy. Treat bodies and attachments as untrusted input, constrain tools, and require approval before consequential sends, forwards, purchases, or account changes.
Do I need to connect a Gmail or Outlook account?+
Not when the agent needs an address of its own. Gmail API and Microsoft Graph are appropriate when a user wants an application to act inside an existing mailbox. An inbound email API is simpler and more private for new application-owned addresses.
Can I use the same platform for normal product email?+
Yes. The same Email Bump project can send transactional messages, receive replies, manage contacts and consent, run campaigns and flows, and expose the CLI, MCP, and agent-skill surfaces.
THE NEXT MESSAGE CAN BE AN EVENT
Give your agent an address.
Start free with inbound email, transactional sending, API, CLI, MCP, campaigns, and flows in one project.