A DimeBox inbox has no IMAP server. No webmail. No folders to file things into, no search index to query, no concept of "mark as read." It has an address, a way to send from it, a way to receive into it, and a flat, time-ordered list of what's happened, capped at the newest few hundred messages. That's the whole feature set. It's worth being explicit that this is a design choice, not an unfinished product.
IMAP exists to synchronize state between a server and a mail client that a human opens, reads, organizes, and closes. It has verbs for marking messages read, flagging them, moving them between folders, searching across years of history — all of it in service of a person deciding what to do with their mail over time. None of that maps onto what an agent does with mail, which is almost always: check if something new arrived, read it, decide what to do, move on. An agent doesn't "open its inbox" the way a person does; it calls an endpoint, gets JSON back, and acts on it in the same process that triggered the check.
Building and maintaining a real IMAP server, with all the state synchronization and client compatibility that implies, is a lot of surface area to support a usage pattern nobody who's calling this API actually has. Gmail API vs an agent-native inbox goes deeper on what changes when the caller is a program instead of a person with a mail client open.
What an agent actually needs from "receiving mail" is much smaller than a mailbox:
DimeBox provides exactly that: GET /api/inboxes/{slug}/messages returns every message, both directions, newest first, with pagination; a single message_id fetches one message's full detail; and a webhook can push a notification the moment something new lands instead of making you poll. See reading a mailbox's history for pagination mechanics and the webhook notifications guide for the push option.
Because there's no archive to maintain, there's also no unlimited history. Each inbox keeps only its newest messages — the default cap is 500 — and older ones are pruned automatically as new ones arrive. That's a direct consequence of treating the inbox as a working buffer rather than a permanent record. The rolling message window covers exactly how that pruning behaves and what it means for anything that needs to outlive the cap.
There are real things a full mailbox gives you that this doesn't: searching years back, filing into folders, forwarding rules, a human ever opening it directly in a browser. If an agent's job genuinely requires that — acting as a long-term archival mail client rather than a point of contact for short-lived correspondence — a DimeBox inbox is the wrong tool, and reaching for one anyway means fighting the shape of the product instead of using it. When you shouldn't use an agent-specific email API is worth reading before committing to this for a use case that's really archival.
For most agent workloads, though — drafting outreach, replying to a thread, confirming a transaction happened — the flat list is enough, and it's considerably cheaper and simpler than standing up a mail client's worth of features to support a caller that was never going to use them. Human inboxes vs agent inboxes lays out the fuller comparison across both directions of that tradeoff.
For the baseline on what an inbox does provide, start with what is an agent inbox.
Lay the two side by side and the gap is specific, not vague:
None of this is free to build and run, and a flat per-call price only works if the thing being charged for stays simple. A mailbox with full-text search across unlimited history, folder rules, and client-compatible IMAP is a materially different, and more expensive, system to operate than a capped, flat list served over a couple of JSON endpoints. Keeping the feature set narrow is part of what keeps the per-call prices — $0.01 to send, $0.03 for priority receive — low enough that paying per call beats the cost of running the equivalent yourself. The true cost of giving every AI agent its own email address goes further into that comparison.