An agent inbox is a real email address — slug@domain — that an AI agent can draft from, send from, and receive into, provisioned by a single HTTP call instead of a signup form. No account, no password, no email-verification loop. The only thing that proves you created it is a token handed back once in the response.
That's the core idea behind DimeBox: treat an email identity as infrastructure an agent requests on demand, the same way it might request a database connection, except the credential here is a working email address other systems can send to and receive mail from.
An agent inbox isn't one API behind one price. It's three distinct operations, each metered on its own:
POST /api/emails/generate, $0.02. Turns a brief (recipient, purpose, optional tone and key points) into a subject/body pair. This one doesn't need an inbox at all — it's pure drafting, with no send and no identity attached.POST /api/inboxes/{slug}/send, $0.01. Sends mail from the inbox's own address, either a raw subject/body or a brief that gets drafted first.Reading what's already in the inbox — GET /api/inboxes/{slug}/messages — is free. You're never charged to look at mail you already paid to send or receive.
Creating the inbox itself has two paths. POST /api/inboxes is free and hands back a randomly generated slug like bold-ember-564, throttled to three per IP per day so the free tier doesn't turn into an unlimited name-hoarding farm. POST /api/inboxes/claim costs $1.00 one-time and lets you pick the slug yourself — see claiming a custom inbox name for how that works and which names are off-limits.
A minimal lifecycle looks like this, using the free path and no payment at all for creation:
curl -X POST https://dimebox.app/api/inboxes \
-H 'Content-Type: application/json'
# 201 response includes read_token and the new address — save both now,
# the token is never shown againFull mechanics, including the exact request and response shape, are covered in how to provision an inbox in one API call.
Every priced call above is gated by the same mechanism used across DimeBox: call it unpaid, get a 402 back describing the price, sign a USDC payment, retry with the signature attached. If you'd rather not sign a payment per call, a card-funded wallet gives you a secret you pass as Authorization: Bearer <wallet_secret> instead — same prices, no 402 round trip. See the wallet page for setup, or the quickstart for both flows in runnable code.
An agent inbox is not a scaled-down Gmail account. There's no IMAP, no webmail client, no folders, no search. It's a flat, time-ordered list of messages capped at the newest few hundred — see why DimeBox inboxes aren't full mailboxes for the reasoning, and the rolling message window for exactly how the cap behaves.
Identity is also handled differently than you might expect. Nobody "owns" an inbox in the account sense — there's no login tied to it, and DimeBox doesn't record which wallet paid to create one. The only thing that controls read access is a token issued once at creation. Who owns an agent's inbox and read tokens explained both go deeper on that model.
Agents lack the things email identity traditionally assumes: a human to click a verification link, a password manager, a reason to remember a recovery address. What they do have is the ability to make an HTTP call and hold a secret in memory for the length of a task. An agent inbox is designed around that constraint — provisioning, sending, and receiving all reduce to HTTP calls a program can make without a human in the loop, each one priced small enough that paying for it beats building the equivalent infrastructure yourself.
For the full argument on why email specifically, rather than some agent-only messaging format, see the complete guide to giving AI agents a real inbox.
In practice, an agent usually provisions an inbox once, near the start of a task that needs a mailing address — kicking off an outreach sequence, standing up a throwaway address to receive a one-time confirmation, or giving a long-running assistant a stable identity for a recurring correspondence. From there, the three priced actions get combined as the task needs them: draft and send a message, wait for a reply by polling or by webhook, read it, and either respond again or move on. None of those steps require going back through provisioning — the inbox, once created, is live for as long as it exists.
Because provisioning, drafting, sending, and receiving are each separate priced calls rather than bundled into one subscription, the cost of running an agent inbox scales with how much it's actually used. An inbox that sends three messages across its lifetime costs three send calls, not a flat monthly fee for capacity that mostly sits idle.