9 Services That Create a Mailbox per Agent by API Call (2026)

The second agent is where it starts. One agent can share a mailbox with a person, or borrow a support alias, and nobody notices. Then the product signs its tenth customer. Each customer wants an agent that sends from its own address, and somebody opens a ticket asking IT for ten new mailboxes.

That ticket is the problem here. An agent that holds real email conversations needs an address it owns, a place where replies land and a history it can read back. A product with many agents needs those inboxes created by code. They should appear when a customer signs up or a test run starts, and go away when they're done.

Plenty of services claim to do this. They differ in what the create call returns and whether the address works the second the call finishes. They also differ in whether each inbox is billed like an employee. Below are nine options compared on those points, then a recommendation by situation.

Three kinds of service create an inbox from an API call

The services fall into three groups, and the group matters more than the vendor. Each one solves a different problem.

Agent-native inbox APIs create a mailbox as a resource in your account. The call returns an address that sends and receives right away. There's no password, license or human user attached. AgentMail, Nylas Agent Accounts and Robotomail work this way.

Test inbox services create disposable addresses for automated tests. They receive mail well and send in a narrower way. Mailtrap Agent Inbox, MailSlurp and Mailosaur started here, and some now market to agent builders too.

Workspace admin APIs create employees. Google Workspace, Microsoft 365 and Amazon WorkMail can each add a user through an API. That user gets a mailbox once a paid license or registration is attached. The inbox is real, and it's also a seat with a password, a directory entry and a monthly bill.

The short answer depends on the inbox's job. Agents that appear and disappear with your customers need an agent-native API. Throwaway addresses that only catch mail during a test are cheaper on a test service. Agents that must sit in a company directory next to staff belong on the admin API you already pay for.

Nine inbox APIs side by side

The table compares each create path: the call, what comes back, the domain, the cheapest way to try it and who it fits. Each service then gets its own section, grouped by kind, with the limits that didn't fit in a cell.

Two columns decide most choices. "What comes back" says whether the address works when the call returns. "Cheapest way in" hints at what the hundredth inbox costs, which is a better test than the price of the first.

Agent-native inboxes are live when the call returns

These three treat the inbox as an API object, the way a storage service treats a bucket. You create it and get an address. Mail sent to that address arrives a moment later.

AgentMail. This is our API, so we'll describe it plainly. A create call needs no fields at all. Leave out the username and we generate one; leave out the domain and the inbox lands on agentmail.to. Pass a client_id and the call is safe to retry, because a repeat with the same id returns the same inbox.

Pass deactivate_at and the inbox shuts itself off at that time. That suits a trial, a fixed-term contract or a single test run. The response carries the inbox id, the address, its pod and its creation time. Store those against your own customer record.

# create one inbox per agent, and a second that switches itself off in a dayimport osfrom datetime import datetime, timedelta, timezonefrom agentmail import AgentMailfrom agentmail.inboxes.types import CreateInboxRequestclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])agent_inbox = client.inboxes.create(    request=CreateInboxRequest(username="acme-support-agent", client_id="acme-support-agent"))trial_inbox = client.inboxes.create(    request=CreateInboxRequest(        client_id="signup-test-run-0412",        deactivate_at=datetime.now(timezone.utc) + timedelta(days=1),    ))print(agent_inbox.email, trial_inbox.email)# output: prints the two new addresses, the second with a generated username

Free includes 3 inboxes and no custom domains, so every Free inbox shares the agentmail.to domain. Developer is $20 a month for 10 inboxes and 10 custom domains. Startup is $200 a month for 150 inboxes, and extra inboxes on either plan are $2 a month each. Pods group inboxes and domains per customer in a multi-tenant product, which the Pods guide covers.

Nylas Agent Accounts. Nylas built its business connecting existing Gmail and Outlook accounts. Agent Accounts are its hosted mailbox product. You create one with a POST to /v3/connect/custom and "provider": "nylas". The only input is an address on a domain registered with Nylas, or on a *.nylas.email trial domain.

The account is live immediately, with six system folders and a primary calendar. You get back a grant_id, the same handle Nylas uses for connected human accounts. Code written for messages, threads and webhooks works on both. Nylas's own CLI guide lists a free sandbox with 3 agent accounts and 200 sends a day. Best for: teams already on Nylas, or agents that schedule meetings.

Robotomail. A small service aimed at one developer and one agent. A POST to /v1/mailboxes with an address creates the mailbox. Replies reach your code by webhook, a server-sent event stream or polling. Mailbox-scoped API keys limit a key to the inboxes you pick.

Pricing is low and the limits are tight. Free gives you 1 mailbox with 10 sends and 10 receives a month, and it only exchanges mail with your own verified address. Solo is $5 a month for one mailbox and one custom domain. Creating several mailboxes by API starts on Starter, $19 a month for 10. Best for: a single agent with a light inbox.

Test inboxes take mail but were built for QA

Test services create addresses fast and cheaply, because most of their inboxes live for minutes. That's ideal for checking that a signup email arrives. It's weaker as the permanent home of an agent that talks to customers.

Mailtrap Agent Inbox. Mailtrap's inbound product, packaged for agents. You create a folder, then an inbox inside it. The response carries the inbox id and an address on inbound-mailtrap.io, with no DNS work. Setup is API-only for now.

The webhook says a message arrived and carries ids, not the body, so you fetch the message in a second call. Attachment links expire after one hour. Failed deliveries retry every 5 minutes, up to 40 times. After that the webhook pauses until someone resumes it, so a long outage means polling to catch up. Received and sent mail share your Mailtrap Email API plan's monthly quota. Best for: teams already sending through Mailtrap.

MailSlurp. A testing platform with a long list of SDKs. createInboxWithOptions with no address returns a random one on a MailSlurp domain. The docs tell you to store that address, because the default domain can change. Catch-all and plus-address routing send related addresses to an existing inbox, which saves one inbox per test case.

The Free plan allows 100 inboxes created and 250 emails received a month. Its inboxes are temporary only. Test sends on Free stay between your own sandbox inboxes, and paid plans start at $19.99 a month. Best for: signup, password reset and one-time code tests.

Mailosaur. A QA tool where the unit is a server, which Mailosaur also calls an inbox. A POST to /api/servers with a name creates one. Every address on that server's mailosaur.net subdomain lands in it. A test can invent a new address per run without another API call. The Personal plan starts at $20 a month billed yearly, with 1 inbox, after a 14-day trial. Best for: QA teams testing what their product sends.

Workspace admin APIs create a person, not an inbox

The admin APIs were designed to onboard employees. They work for agents, and teams use them when security wants every mailbox in the company directory. Each step still assumes a human on the other end.

Google Workspace. The Directory API's users.insert creates a user on a domain you've already proved you own. Google's user management guide says the mailbox comes only with purchased mail licenses. Activation may take a few minutes. Create users too fast and the API returns 503 until you back off.

Every agent is also a full Google account with a password. Its organizational unit decides which Google services it can reach. A user deleted in the last 20 days can usually be restored, which helps when an agent is removed by mistake. Best for: agents that must appear in a Google directory.

Microsoft 365. Graph POST /users needs the User.Create permission and a user principal name on a verified domain. It also wants a display name, a mail nickname and a password profile. That creates the identity. The mailbox arrives when you assign an Exchange license with a second call to assignLicense, and each license is a monthly charge.

Microsoft notes that federated users created this way must sign in every 12 hours by default. That rule was written for people, and an agent account inherits it. Best for: agents inside a tenant your company already runs.

Amazon WorkMail. CreateUser makes a directory user, and RegisterToWorkMail turns it into a mailbox. The bigger issue is the date. AWS ends support for WorkMail on March 31, 2027, and the console and its resources go with it. Best for: WorkMail teams who need a stopgap while they move.

Our recommendation by agent count, domain and inbox lifetime

Three questions settle the choice. How many inboxes will you have in a year? Whose domain do they send from? How long does each one live?

A few long-lived agents on your own domain fit almost anything. Robotomail is the cheapest for one agent. Our Developer plan covers 10 inboxes on 10 domains. If those agents also need calendars, Nylas Agent Accounts are worth the extra integration work.

Hundreds of inboxes created by code rule out the admin APIs on cost alone, since each one is a license. They rule out test services for customer-facing work too. Temporary inboxes and capped sending don't hold a customer conversation. This is where an agent-native API earns its place, and where we built AgentMail to sit. The arithmetic stays linear: 250 inboxes on Startup is $200 plus 100 extra at $2, so $400 a month.

Short-lived inboxes depend on who reads them. A test that only waits for a verification code belongs on MailSlurp or Mailosaur. An agent that signs up for a service and keeps using the account needs an inbox that lasts. There, deactivate_at and a clean delete matter more than a fast create.

Reputation is the last check. Sender reputation attaches to the domain, not the inbox, on every service here. Agents on one domain share a reputation, so one customer's bad sending can hurt the rest. Separate customers belong on separate domains. Our guide to custom domains for thousands of agent inboxes walks through it, and the fleet use case shows it at scale.

Weighing an inbox per agent against one catch-all address is its own decision, covered in catch-all vs inbox per agent. For the wider field of sending and receiving APIs, see our roundup of email APIs for AI agents.

What AgentMail does not do

We don't open or manage an existing Gmail or Outlook mailbox; Nylas connects those, and the admin APIs above own them. Our Free plan has no custom domains, so Free inboxes share the agentmail.to domain and its reputation. We also don't host calendars, which matters if your agent books meetings from its own account.