# Email API for AI agents

> Give AI agents application-owned email addresses they can receive, read, reply, forward, and send from through one API.

- **Canonical page:** [https://emailbump.com/email-api-for-ai-agents](https://emailbump.com/email-api-for-ai-agents)
- **Implementation guide:** [Agent mailbox in five minutes](https://emailbump.com/docs/agent-mailbox.md)
- **API reference:** [Inbound Email API](https://emailbump.com/docs/inbound-api.md)

## The mailbox model

Each Email Bump project gets a catch-all inbound domain. Every local part works without provisioning an inbox object, so an application can assign stable addresses per agent, customer, ticket, invoice, or run. The address routes the message; authorization still belongs in application state.

Use a dedicated application address when an agent needs a new identity of its own. Use Gmail API or Microsoft Graph when the product truly needs to act inside an existing human mailbox.

## Receive and react

1. Send a message to any address on the project's inbound domain.
2. Observe a signed **email.received** webhook or a WebSocket event.
3. Fetch the full message only when the workflow needs its body, headers, or attachment list.
4. Apply application policy and decide whether the agent may reply, forward, escalate, or do nothing.
5. Reply against the inbound message ID so threading headers are assembled from the original message.

~~~bash
# List waiting messages
curl 'https://emailbump.com/api/v1/inbound?limit=10' \
  -H "Authorization: Bearer $EMAILBUMP_API_KEY"

# Read one message
curl 'https://emailbump.com/api/v1/inbound/MESSAGE_ID' \
  -H "Authorization: Bearer $EMAILBUMP_API_KEY"

# Reply in the original thread
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." }'
~~~

## Capabilities

- Catch-all addresses without mailbox provisioning
- Signed inbound webhooks and WebSocket events instead of polling
- Text and HTML bodies, participants, threading headers, authentication and spam results
- Attachment metadata followed by an explicit download
- Threaded replies using the inbound message ID
- One-time forwarding and standing forward rules
- Transactional sending, delivery events, contacts, campaigns, and flows in the same project
- Direct REST API plus CLI, MCP server, and open agent skills

## Safety boundary

Email bodies and attachments are untrusted input even when SPF, DKIM, and DMARC pass. Authentication is evidence about sender identity, not permission to execute instructions.

- Keep agent tool access narrow and credentials scoped to the required project.
- Resolve address ownership and sender authority from trusted application state.
- Inspect attachment metadata before downloading bytes, and keep active content outside privileged origins.
- Require human confirmation before consequential replies, forwards, purchases, credential changes, or disclosure of sensitive data.
- Record message IDs, decisions, tool calls, and outbound results for review.

## Common uses

- Support queues that classify, draft, answer, or escalate conversations
- Confirmation readers for explicitly authorized account workflows
- Invoice and document intake with deliberate attachment handling
- Workflow mailboxes that turn replies, approvals, and exceptions into durable application events

## Related guides

- [Email inbox API guide](https://emailbump.com/blog/email-inbox-api.md)
- [Email API buyer's guide](https://emailbump.com/blog/email-api.md)
- [Send email with a REST API](https://emailbump.com/blog/send-email-rest-api.md)
- [Free email API comparison](https://emailbump.com/blog/free-email-api.md)
- [Email Bump MCP server](https://emailbump.com/mcp.md)
- [Email Bump CLI](https://emailbump.com/cli.md)