Signing up for an API account is a five-minute task for a human: an email address, a password, maybe a verification click. For an agent, it's a different kind of problem entirely — an agent that needs to provision a resource mid-task doesn't have an email address to verify yet (that may be exactly what it's trying to get), doesn't have a human watching for a confirmation link, and often doesn't have a session that persists long enough to come back and finish onboarding later. A signup flow designed around a human sitting at a keyboard is a wall for a caller that isn't one.
Account creation assumes a few things that hold for humans and often don't for agents: that the caller has a persistent identity worth attaching a password to, that someone will be present to click a verification link, and that the relationship between caller and provider is long-lived enough to justify the setup cost. An agent spun up to do one task and then discarded has none of those properties. Forcing it through account creation anyway means either a human has to provision credentials on the agent's behalf ahead of time, defeating a lot of the point of delegating the task, or the agent simply can't use the API at all.
DimeBox's approach is to make the resource itself the credential. Provisioning an inbox for free returns a read token in the same response — there's no separate account to create first, nothing to verify by email (which would be circular, since the inbox is the thing being created), and no password to set. Paid actions work the same way: a signed payment or a wallet secret authorizes the specific call being made, rather than authenticating a pre-existing account. The credential is scoped to the resource, issued at the moment of creation, and good for nothing beyond that resource.
curl -X POST https://dimebox.app/api/inboxes \
-H 'Content-Type: application/json'That single call is the entire onboarding flow: no account created beforehand, no email to verify, no dashboard to log into afterward — just a resource and a credential, returned together.
This isn't unique to email. Any API that an agent needs to use unsupervised faces the same mismatch between human-shaped onboarding and machine-shaped usage, and the same fix generally applies: let the first call create the resource and its credential together, rather than requiring a separate setup step beforehand.
No-signup access isn't free of consequences. Without an account, there's no password reset, no "forgot my credential" flow, and in DimeBox's case, no record of which wallet paid to create a given inbox, which is a deliberate privacy choice, not an oversight, but it does mean there's genuinely nothing to recover if a read token is lost. Comparing this against API keys and OAuth-style delegation makes the tradeoff clearer: those models buy recoverability and auditability at the cost of an account a human has to set up and manage. No-signup access buys immediacy at the cost of that recovery path.
Skipping an account doesn't mean skipping abuse prevention — it just means the limits apply to the call itself rather than to a registered identity. The free inbox-provisioning route is throttled per IP rather than per account: three per day, enforced without ever asking who's calling. That's a deliberately different shape of rate limit than the per-account quotas a signed-up API would use, and it's the shape that actually works when there's no account to attach a quota to in the first place. It also means a caller can't appeal a throttle by proving who they are, since there's no identity on file to appeal with — the limit is a property of the request pattern, not of an account in good standing.
As more of the traffic hitting an API is a machine deciding on its own, mid-task, that it needs this specific resource right now, the fraction of callers that can tolerate a multi-step signup flow keeps shrinking. A human will put up with account creation because they only do it once per service. An agent that might provision a disposable resource dozens of times across dozens of short-lived tasks can't absorb that cost at all, not because agents are impatient, but because the economics of a five-second task don't support a five-minute setup step repeated every time. Multiply that five minutes by however many disposable resources a fleet of agents provisions across a single day's tasks, and a human-shaped signup flow stops being a minor inconvenience and starts being the dominant cost of using the API at all, long before the API's own per-call price ever becomes the bigger line item.