DimeBox has four priced actions: draft an email ($0.02), send from an inbox ($0.01), receive a message on the priority channel ($0.03), and claim a custom inbox name ($1.00, one-time). They do completely different things — one calls out to generate text, one queues outbound mail, one writes an inbound message directly into history, one reserves a name. All four are wrapped in exactly the same payment gate.
Every paid route follows the identical sequence: call it without payment and get back a 402 describing the price, due to a specific PAYMENT-REQUIRED header; sign a payment and retry with PAYMENT-SIGNATURE; or skip that entirely with Authorization: Bearer <wallet_secret> against a funded DimeBox wallet. See how a 402 response actually works, step by step for the full handshake. Either path ends the same way: the route's own handler runs, and a payment settles only if that handler's response comes back under 400.
The shape is identical whether you're hitting the drafting endpoint or the send endpoint — only the price and the body differ:
# 1. Call unpaid — any paid route responds the same way
curl -i -X POST https://dimebox.app/api/inboxes/acme-support/send \
-H 'Content-Type: application/json' \
-d '{"to":"[email protected]","subject":"Hi","body":"..."}'
# 402 Payment Required
# PAYMENT-REQUIRED:
# 2. Sign the payment described in that header, then retry with it attached
curl -i -X POST https://dimebox.app/api/inboxes/acme-support/send \
-H 'Content-Type: application/json' \
-H 'PAYMENT-SIGNATURE: ' \
-d '{"to":"[email protected]","subject":"Hi","body":"..."}'
# 202 Accepted — now, and only now, does payment settle Swap the URL, method, and body for /api/emails/generate, /api/inboxes/claim, or the priority /api/inboxes/{slug}/messages route and the sequence above doesn't change at all — same two steps, same two headers, same rule about when settlement happens.
The practical consequence is that you only have to learn this once. Figure out the 402-or-wallet-secret flow against the drafting endpoint, and sending, priority receive, and claiming all work exactly the same way — same header names, same retry pattern, same charging rule. There's no route where a 422 somehow still charges because that particular handler was written slightly differently, and no route where a successful-looking response secretly didn't charge due to an inconsistency elsewhere. One mental model covers every priced action on the product.
This also means the failure-mode guarantees are uniform, not endpoint-specific promises you have to verify one at a time: a 415 for the wrong Content-Type is rejected before the payment gate is even reached, so it never charges on any route; a 422 for bad input never charges even though the route is a paid one; a 502, meaning the facilitator itself was unreachable, never charges either. DimeBox never charges for a failed call is the policy; this uniform gate is the mechanism that makes the policy actually true everywhere rather than true as a goal that each route individually has to implement correctly.
A system where every paid route independently decided when to charge would only be as trustworthy as its least careful implementation. One route's handler forgetting to check a status code before settling payment would be a real, exploitable bug — not in the gate's design, but in that one place where the design wasn't actually followed. Routing every priced action through one shared gate removes that category of bug entirely: there's no per-route charging logic to get subtly wrong, because there's no per-route charging logic at all. The decision of whether to settle lives in exactly one place, applied uniformly, rather than copy-pasted (and potentially drifting) across four different handlers.
It also means a caller auditing DimeBox's behavior — reading the status codes and charging reference instead of trusting marketing copy — only has one gate's behavior to verify, not four separate implementations that happen to claim the same behavior.
In practice, you'll notice this as consistency rather than as a named feature: an agent that already knows how to pay for one DimeBox call doesn't need special-cased logic for the others. The same retry loop, the same header parsing, the same assumption that an error response never cost anything, carries across drafting, sending, priority receive, and claiming without modification. That's also why a threat model for pay-per-call APIs built on x402 can reason about DimeBox's paid surface as one gate with four doors, rather than four separate systems that each need their own audit.
It's also why the wallet-secret shortcut doesn't fork the model into two different sets of rules. Authorization: Bearer <wallet_secret> skips the 402-and-retry round trip, but it still goes through the same gate on the other side — the handler still runs, and the same under-400 rule still decides whether the wallet actually gets charged. The two authentication paths differ in how you get to the gate, not in what the gate does once you're there, which is exactly what lets a caller treat "pay with a signature" and "pay with a wallet" as two doors into one room instead of two different rooms.