Provisioning an inbox is free. POST /api/inboxes (see the full provisioning reference) costs nothing, requires no signature, and hands back a working {slug}@ address with a read token in one call. That's exactly the property that makes an agent-native inbox useful — no signup, no waiting on email verification, no credit card to stand up a mailbox for a short-lived task. It's also the property that makes the same endpoint attractive to abuse: if creating a mailbox costs nothing and takes one request, creating a thousand mailboxes costs nothing and takes a thousand requests, whether they're for legitimate agents or for spam infrastructure, phishing landing addresses, or disposable throwaway accounts.
The free route is throttled to 3 requests per day, per IP address. That's a narrow allowance deliberately — enough for a developer standing up a couple of test inboxes while building something, not enough to mass-provision mailboxes from a single machine. Past that, the route returns a 429 until the window resets.
IP-based throttling has a well-known weakness: it conflates "the same caller abusing the endpoint" with "many different callers who happen to share an egress address" — behind corporate NAT, a university network, a VPN, or a cloud provider's shared outbound IPs. A legitimate team running several agents from the same office or the same cluster can realistically hit the ceiling without any abuse happening at all.
The alternative would be rate-limiting by account or by identity — the normal approach almost every API takes. DimeBox doesn't have that option by design: there's no signup, so there's no account to attach a quota to, and no login to use as the throttling key instead of an IP. IP is the only signal available before any identifying information exists, which is the trade DimeBox is making here: a somewhat blunt free-tier limit, in exchange for not requiring the signup step that a cleaner per-account limit would need. See how one-call provisioning works for what you get from that trade on the other side.
Notice that POST /api/inboxes/claim — picking your own name instead of a random one — isn't rate-limited the same way. It doesn't need to be: it costs a flat $1.00 per claim, settled through the same x402/wallet gate as every other paid route on DimeBox. A price is already a rate limit; mass-claiming names at a dollar each scales the abuser's cost linearly with volume, which the free route structurally can't do. This is the general pattern across DimeBox's pricing — see why charging in cents changes how agents behave for more on how a small, real price shapes volume differently than a free tier ever can. The IP throttle on the free route and the per-claim price on the paid one are two different tools solving the same problem — keeping volume economically or practically bounded — chosen because only one of those tools is available where no payment is involved.
For the overwhelming majority of legitimate use, this limit is invisible. A single agent task needs one inbox, used for its duration, not three new ones a day — and most integrations provision an inbox once and keep using the same slug and read token going forward rather than creating a fresh one per run. The ceiling only becomes visible to patterns that look like abuse from the outside even when they aren't: rapid, repeated inbox creation from one IP, which is also exactly the shape mass provisioning takes. If your use case genuinely needs more than three fresh, random inboxes a day from the same network, claiming named inboxes — at a real, volume-scaling price — is the intended path past the free tier's limit, not a workaround for it.
Rate-limiting free creation is one layer among several that keep the no-signup model from becoming an open door. It pairs with reserved name blocking, which stops the specific, high-value slugs abuse tends to target even when creation itself isn't throttled, and with enumeration-resistant identifiers, which stop an attacker from discovering existing inboxes even if they can't create new ones freely. None of these controls assumes an account exists to fall back on — each has to work on its own, because for the free tier, an account is exactly what isn't there.
Three a day per IP sounds restrictive until you consider what the free route is actually for: giving a single agent a mailbox to use for the lifetime of a task, not minting disposable addresses on a schedule. A system that needs many distinct inboxes running concurrently — a fleet of agents, each with its own identity — is a different shape of problem than the free route was ever meant to solve by itself. Spreading creation across more than one IP, spacing it out over more than one day, or claiming named inboxes outright are all legitimate ways to get there; none of them require asking DimeBox to raise a limit, because there's no request process to raise it through in the first place.
It's also worth noting what the throttle doesn't touch: reading an existing inbox's messages, sending from one you already control, and paying for priority receive are all unaffected by how many free inboxes you've created that day. The limit is scoped narrowly to the act of minting a new, random address — the one action that's genuinely free and genuinely repeatable at no cost to whoever's calling it.