# Give your agent an inbox. Put it to work.

A real email address your agent can send from, receive into and reply from. Build conversations with customers, teammates and other agents using Robotomail.

For developers connecting an agent to an email workflow. Bring your own model and application logic.

[Create a mailbox](/sign-up) · [See plans](/pricing)

## An email identity for the work your agent does

An agent can write a response. To carry out a real email workflow, it also needs an address, somewhere to receive replies and a way to recover the conversation when the next message arrives.

Robotomail gives your software mailboxes it can control through an API. A support agent can receive a question, load the thread and send a reply from the same address. A research assistant can ask for information and continue when the answer arrives. Separate mailboxes let you keep different agents and tasks distinct.

You control the agent, its instructions and when it is allowed to act. Robotomail handles the email interface: mailbox creation, sending, inbound messages, conversation threads, attachments and events.

## From an address to a working conversation

1. **Create a mailbox.** Choose an address during signup, or provision mailboxes through the API. Use a platform address to begin; add a verified custom domain on a paid plan when you need your own identity. (`POST /v1/mailboxes`: `support@agents.example.com`)
2. **Connect your agent.** Use the REST API, an SDK, MCP or an agent integration. Keep credentials on the server and limit access to the mailboxes the workflow needs. (`scoped key`: `rm_…9c2 · mailbox access: support`)
3. **Receive the first message.** Subscribe to inbound webhooks, connect to the event stream or poll the messages API. Fetch the message and relevant thread before deciding what to do. (`webhook event`: `message.received
→ GET /v1/mailboxes/:id/threads/:threadId`)
4. **Apply your rules.** Check the sender, recipients, requested action and any attachments. Your application decides whether to reply, request human approval or hand off the conversation. (`your application`: `if (needsApproval) → queue.review()
else → agent.reply()`)
5. **Send and follow up.** Reply with the original RFC email Message-ID in inReplyTo. Record the send result and handle delivery or bounce events separately. (`POST /v1/mailboxes/:id/messages`: `{ inReplyTo: "<8f2c41@customer.example>" }
→ message.delivered`)

Start with a single conversation you can verify end to end. The [quickstart](/docs/quickstart) covers the first mailbox; [receive and reply](/docs/guides/receive-and-reply) covers the inbound loop.

## Start with a job you can measure

### Customer support

Route a support address to your application. Answer what you can ground in help content, pass billing disputes and uncertain answers to a person. [Build a support workflow](/use-cases/customer-support)

### Lead qualification

Give an inquiry a real reply address. Ask for missing details, keep responses in a thread and hand qualified leads to your team. [See the lead workflow](/use-cases/lead-qualification)

### Product onboarding

Send setup messages from your product, then let users reply when they get stuck. Robotomail transports the email and returns replies. [See the onboarding workflow](/use-cases/saas-onboarding)

### Multiple agents

Give each role a separate mailbox and constrain which ones each API key can access. Your orchestrator owns task state and permissions. [Explore multi-agent workflows](/use-cases/multi-agent-workflows)

## The pieces a conversation needs

| Capability | What it gives your application |
| --- | --- |
| Mailboxes | An address for an agent, workflow or customer-facing role |
| Send and receive | Both sides of an email conversation through one API |
| Threads | Related messages to load before generating the next reply |
| Attachments | Uploads for outgoing messages and metadata and retrieval for incoming files |
| Webhooks and events | A signal when new mail or delivery events arrive |
| Custom domains | Addresses on a domain or subdomain you configure and verify |
| Scoped keys | API access limited to the mailboxes a workflow needs |

The email service does not decide whether an instruction in a message is safe. Keep your agent's permissions, approval rules and customer data access in your application.

## Connect the way you already build

Use the [REST API](/email-api-for-ai-agents) when you want direct control over provisioning and message handling. Use the [SDKs](/docs/sdks) when you prefer language-level helpers.

For a tool-using agent, [MCP](/docs/mcp) exposes email actions through the model's tool interface. The [Build hub](/build) brings together Claude Code, OpenClaw, Hermes, Grok Bot, Muse and the reusable agent skill, with a path from setup to the first conversation.

An integration makes email accessible to the agent. It does not replace your application's authorization checks or turn incoming email into trusted instructions.

[REST API](/email-api-for-ai-agents) · [SDKs](/docs/sdks) · [MCP](/docs/mcp) · [Claude Code](/build/claude-code) · [OpenClaw](/build/openclaw) · [Hermes](/build/hermes) · [Grok Bot](/build/grok-bot) · [Muse](/build/muse) · [Agent skill](/skill)

## Make the first workflow safe to run

Before allowing automatic replies, test with addresses you control and verify your account before sending. A delivery event means the recipient server accepted the message; it does not prove a person read it.

If you use your own domain, publish the DNS records returned during setup and wait for verification. A dedicated subdomain keeps agent email separate from staff email. See [custom domain setup](/docs/guides/custom-domain), [email delivery](/docs/guides/email-delivery) and [agent email security](/docs/guides/agent-email-security).

- [ ] Test with addresses you control
- [ ] Verify the account before sending
- [ ] Limit the actions an agent can take
- [ ] Keep API keys out of prompts and logs
- [ ] Store only the conversation data the task needs
- [ ] Dedupe webhook retries before acting
- [ ] Track message and thread IDs in your app
- [ ] Monitor bounces and suppress complainers

## Is Robotomail a fit for your project?

Robotomail fits when you are building software that needs its own email identity and an inbound reply loop. You bring a model or agent, a place to run it and the rules for what it should do.

Choose a plan around the mailboxes, send volume, inbound volume and storage your workflow needs. Check [current pricing](/pricing) before committing to a rollout, then test one real conversation before expanding.

If you need to operate inside an existing person's inbox, review the account access requirements separately. A new Robotomail mailbox does not automatically import another provider's messages. For agent-owned addresses and controlled application workflows, start with a mailbox and connect the smallest useful task.

## Common questions

### Does Robotomail include the AI agent?

You bring the agent, model and workflow. Robotomail gives that software email addresses, messages, threads and events through an API and integrations.

### Can each agent have its own email address?

Yes. Provision separate mailboxes within your plan limits and use mailbox-scoped API keys where the workflow needs restricted access.

### Can I use my own domain?

Yes, on a paid plan. Add the domain, publish the DNS records returned by Robotomail and complete verification before using it for mailboxes. A subdomain is useful when your main domain already handles staff email.

### What should I build first?

Choose one inbound conversation, such as a support question. Receive it, load the thread, review the proposed response and send a reply. Validate the whole loop before adding more autonomy.

### What's included in the Free plan?

1 mailbox, 10 sends and 10 receives per month, only between your agent and your verified email address. No credit card, no expiry. Allowances reset on the first of each month (UTC). Upgrade to email other people or use a custom domain.

## Continue building

- [Email API for AI agents](/email-api-for-ai-agents)

- [Choose an integration](/build)

- [Why we built Robotomail](/blog/introducing-robotomail)