Agents retry things. A network call times out, a process restarts mid-task, a load balancer closes a connection before the response finishes arriving — and the obvious response is to just send the request again. For a free, read-only call that's harmless. For a paid call that drafts an email, sends one, or delivers a priority message, "just retry" raises the real question behind the term idempotency: if I'm not sure whether my last request actually went through, is it safe to send it again, or will I pay twice and send the same email twice?
DimeBox doesn't have a dedicated idempotency-key header you attach to a request to make retries explicitly safe. What it has instead are two structural properties that cover most of the same ground, plus one gap worth knowing about.
Every paid route on DimeBox settles payment only if its own response comes back under 400. A 402 (no valid payment yet), a 422 (bad input), a 415 (wrong content type), or a 502 (the facilitator was unreachable) never charges anything, regardless of which paid route returned it. See why every paid route is wrapped in the same gate for the mechanism behind this. Practically, this means retrying after any error response is always safe from a billing standpoint — there's nothing to double-pay for, because the failed attempt was never charged in the first place.
When you pay over x402's exact scheme, the signature you produce authorizes a specific EIP-3009 transferWithAuthorization — and that authorization is bound to a nonce as part of the standard itself, not something DimeBox adds on top. A given signed authorization settling once is a property of the token standard, not a DimeBox-specific safeguard: replaying the identical signed payload a second time doesn't move funds twice. That doesn't make a second, freshly-signed payment attempt interchangeable with the first — it just means the exact signed bytes you already used can't be spent again, which rules out one specific failure mode (accidentally resubmitting the same signature) without saying anything about a second, independently-signed retry.
Here's what neither property covers: if your client sends a request, DimeBox processes it successfully and returns 202 Accepted, but your client never sees that response — a timeout on your end, a dropped connection — and you respond by building and sending an entirely new request (a new signature, or another Bearer-authenticated call against a wallet), DimeBox has no way to know those two requests were "the same" send. From its point of view, two valid, successful requests arrived, and it did what each one asked: two emails sent, two charges settled. Nothing about the gate or the signature scheme is wrong here; both requests really were legitimate and complete on their own.
Because a send doesn't complete synchronously — the 202 response means queued, not delivered, and the real outcome shows up later as sent or failed — you already have a cheap, free way to check what actually happened before retrying: read the mailbox. GET /api/inboxes/{slug}/messages costs nothing and needs only the X-Inbox-Token. If you're unsure whether a send you issued a minute ago actually went through, check history for a matching message in queued or sent state before firing off a second attempt. That one read is the closest thing to an idempotency check available today — not a key you attach to the request up front, but a free lookup you run before deciding whether a retry is actually necessary.
It's tempting to assume the card-funded wallet path, paying with Authorization: Bearer <wallet_secret> instead of a signed payment, is at least as safe to retry as the x402 path, since it skips the whole signature step. It's actually the opposite: a Bearer-authenticated call has no per-request nonce at all. Nothing about the credential itself prevents two identical requests from being treated as two independent, successful actions — the only thing standing between you and a duplicate send on that path is still the charge-only-on-success rule plus checking history before retrying, with none of the extra replay protection a freshly-signed EIP-3009 authorization happens to provide as a side effect of the standard. The wallet path trades that narrow protection for skipping the 402 round trip; it doesn't get both.
If you're writing retry logic against DimeBox, the safe default is: retry immediately and without hesitation on any error response, since those never charged. Before retrying anything that might have actually succeeded without your knowledge — a send, a priority receive, a claim — check the inbox or your own local state for evidence it already happened first. That's a cheap habit that costs one free GET request, against the alternative of paying for, and sending, the same thing twice. It matters slightly more on the wallet-secret path than the signed-payment path, precisely because the signed path happens to get a little replay protection for free and the Bearer path doesn't.