The 5-Minute Mailbox

Nylas has introduced Agent Accounts, which allow developers to provision a fully functional email mailbox via a single API call in under five minutes, eliminating the need for OAuth flows and IT intervention. The service, currently in beta, enables applications to own mailboxes end-to-end for use cases such as system addresses, ephemeral test inboxes, and AI agents that can send, receive, and manage calendar events. This shift treats email addresses as programmatic resources rather than pre-planned identities, similar to how cloud APIs transformed virtual machine provisioning.

The email mailbox just became an API resource, and that matters far more than the setup time it saves. For most of software history, a real email address — one that sends, receives, and threads — was an artifact of IT process. Someone created it in an admin console, someone else configured the client, and your application got access through OAuth consent screens and refresh tokens borrowed from a human. Compare that to how you get a database, a queue, or a TLS cert today: one API call, one ID back, done. Nylas Agent Accounts currently in beta close that gap. The quickstart https://developer.nylas.com/docs/v3/getting-started/agent-accounts/ goes from API key to a sending-and-receiving mailbox in under 5 minutes, and the provisioning step is a single request: curl --request POST \ --url "https://api.us.nylas.com/v3/connect/custom" \ --header "Authorization: Bearer <NYLAS API KEY " \ --header "Content-Type: application/json" \ --data '{ "provider": "nylas", "settings": { "email": "test@your-application.nylas.email" } }' No refresh token, no OAuth dance — unlike OAuth providers, the "nylas" provider needs only an email address on a registered domain. The response contains a grant id , and that one ID drives everything else: messages, drafts, threads, folders, attachments, calendar, webhooks. There are actually three ways to create an account — this API call, the Dashboard, or a single CLI command nylas agent account create — but they all end at the same place: a live mailbox. Provisioning time isn't a linear cost. There's a threshold below which a resource changes category — from "thing you request" to "thing your code creates." Virtual machines crossed it with cloud APIs and we got autoscaling. TLS certs crossed it with ACME and we got HTTPS-by-default. Mailboxes crossing it means email addresses stop being scarce, pre-planned identities and start being something a program allocates when it needs one. What does that look like in practice? System mailboxes without ceremony. A support@ or scheduling@ address your app owns end-to-end — no consent screen, no integration that breaks when an employee offboards. The docs' framing is exact: a mailbox your application owns, not borrows. Ephemeral inboxes. Spin up an address for a test run, a workflow, or a single customer interaction, then delete the grant. A concrete version: your CI pipeline creates e2e-run-4821@yourapp.nylas.email , your signup flow sends its verification email there, the test asserts on the real delivery — not a mock — and teardown is one delete on the grant. When creation costs one HTTP call, teardown becomes a reasonable habit instead of a cleanup chore you defer forever. Identity for agents. An AI agent with its own address can send, receive replies in-thread, and even RSVP to calendar invites — every account ships with a primary calendar that speaks standard iCalendar, so Google Calendar, Microsoft 365, and Apple Calendar treat it as a normal participant. The send-rsvp endpoint means the agent's "yes" shows up like anyone else's. Plenty of services let you send email programmatically in minutes. The unusual part here is that the mailbox receives , and inbound mail fires the standard message.created webhook — identical in shape to the same event for a Gmail or Outlook grant. Register a webhook once: nylas webhook create \ --url https://yourapp.example.com/webhooks/nylas \ --triggers message.created …and replies land in your handler seconds after they arrive. If you'd rather not run webhook infrastructure yet, polling GET /v3/grants/{grant id}/messages works too. Either way, the loop closes: your code can ask a question over email and react to the answer. The send half deserves a sentence as well. Outbound goes through the same POST /v3/grants/{grant id}/messages/send endpoint used for any connected grant, and the recipient sees a normal message from the agent's own address — no "sent via" branding, no relay footer. Outbound messages are capped at 40 MB total. The whole point of the design is that an Agent Account is just another grant: the message.created payload is identical in shape to the one a Gmail or Outlook grant produces, and you branch on the grant's provider field "nylas" only if you need to tell them apart. Everything you've already built — pagination, attachment downloads, thread fetches — works unchanged. Instant shouldn't mean careless, and there are two qualifiers worth stating plainly. First, the 5-minute path uses a .nylas.email trial subdomain — instant because there's no DNS involved. For production you'll want your own domain, which means publishing two kinds of DNS records MX for inbound routing, TXT for ownership and SPF/DKIM and waiting for propagation before verification completes. That's a one-time cost per domain, not per mailbox, but it's real. The docs recommend a dedicated subdomain like agents.yourcompany.com so your agents' sender reputation stays isolated from your primary domain — see provisioning and domains https://developer.nylas.com/docs/v3/agent-accounts/provisioning/ . Second, cheap creation makes governance more important, not less. The defaults are sane — the free plan caps sending at 200 messages per account per day, with 3 GB of storage per organization and 30-day inbox retention — but defaults aren't a strategy. Every account you create without an explicit workspace id lands in your application's default workspace, so attaching a policy and rules there governs all of your unassigned mailboxes in one move. The policies and rules system https://developer.nylas.com/docs/v3/agent-accounts/policies-rules-lists/ exists for exactly that, and it's worth configuring before your mailbox count gets interesting. You could also argue most apps don't need a receiving mailbox at all — transactional send-only covers password resets fine. True. But the moment your product wants a conversation rather than a notification — support, scheduling, anything an agent does — the send-only model runs out, and historically the next step was a painful jump to "go provision accounts with an email admin." Now the next step is a POST request. Try the threshold test yourself: start a timer, follow the quickstart https://developer.nylas.com/docs/v3/getting-started/agent-accounts/ , and stop when you've sent yourself an email from the new address and seen the reply come back through a webhook. If you beat 5 minutes, ask the more interesting question: what would you build if mailboxes were as disposable as containers?