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.
- From alex@customer.exampleInboundCan you help me get connected?
I created my account but I'm not sure which integration to use. We're building with Claude Code.
- waiting for event…
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
- 01Create 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/mailboxessupport@agents.example.com
- 02Connect 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 keyrm_…9c2 · mailbox access: support
- 03Receive 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 eventmessage.received → GET /v1/mailboxes/:id/threads/:threadId
- 04Apply 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 applicationif (needsApproval) → queue.review() else → agent.reply()
- 05Send 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 covers the first mailbox; receive and reply covers the inbound loop.
Start with a job you can measure
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 when you want direct control over provisioning and message handling. Use the SDKs when you prefer language-level helpers.
For a tool-using agent, MCP exposes email actions through the model's tool interface. The Build hub 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.
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, email delivery and agent email security.
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 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
You bring the agent, model and workflow. Robotomail gives that software email addresses, messages, threads and events through an API and integrations.
Continue building
Start with one mailbox. Build the workflow you need.
Create a mailboxChoose a mailbox, connect your agent, then test a conversation.