Two credentials control everything about a DimeBox inbox or wallet after it's created: the inbox's read token, and a wallet's wallet_secret. Both are shown exactly once, at creation or funding time, in the response body — and neither can be retrieved again afterward. There's no "view my token" screen, no "resend my secret" email, because there's no account to send anything to and nothing stored that could be shown back to you even if there were somewhere to send it.
A system that could show you your token again would have to be holding it, or something reversible to it, somewhere. That's the normal way most systems store API keys, and it's also exactly why a leaked database full of API keys is a leaked database full of working API keys. DimeBox's "no recovery" behavior for read tokens and wallet secrets is the visible symptom of a different storage choice underneath: rather than keeping a value it could hand back to you, it keeps a one-way hash of that value, and checks future requests by hashing whatever credential they present and comparing it against what's stored.
That comparison is all authentication needs to be. When a request arrives with an X-Inbox-Token header or a wallet_secret Bearer token, DimeBox doesn't need the original value to decide whether the request is legitimate — it only needs to know that hashing the presented value produces the same output as what it already has on file. The original plaintext value never has to exist on DimeBox's side after the moment it was first generated and returned to you.
It would be easy to read "shown once, no recovery" as a deliberately strict policy layered on top of a system that could, technically, show you the value again if it wanted to. It's closer to the reverse: the lack of a recovery flow is the consequence of the storage model, not an arbitrary restriction added to an otherwise-recoverable secret. There is no plaintext copy sitting anywhere waiting to be displayed again, support flow or not. Losing a read token really does mean losing access to that inbox's message history permanently, because the one party that could theoretically help — DimeBox itself — genuinely doesn't have the value either.
This matters most in the failure case nobody wants to think about: what if DimeBox's own storage were ever compromised. A one-way hash sitting in a database isn't the credential — it's a value that's computationally expensive to reverse into the original token, the same property that makes a leaked password-hash table not the same thing as a leaked password list. An attacker with access to stored hashes would still need to brute-force each one individually to recover a usable token, rather than reading working credentials straight off the page. It's not a guarantee that a breach is harmless, but it's the difference between a breach exposing secrets directly and a breach exposing values an attacker would still have to do real work to turn into secrets.
This isn't limited to the read token. A wallet's secret follows the identical shape — generated once at funding time, never displayed again, checked by comparison rather than retrieval. A webhook secret, issued when you set a webhook_url at provisioning time, works the same way too: it's shown once so you can store it on your own side, and from then on it's used to verify the X-DimeBox-Signature: sha256=<hmac> header on incoming webhook calls (see the webhook reference for the full verification flow) — a comparison DimeBox's own system runs the same way, using a value it keeps rather than one it ever needs to show you a second time.
Because none of these secrets can be recovered or re-displayed, the practical consequence is entirely on your side: store the read token, wallet secret, and webhook secret the moment you receive them, in whatever secrets manager or environment configuration your own system uses. There's no fallback if you don't — not a slower recovery process, not a support ticket, nothing. The absence of a recovery flow isn't DimeBox withholding a feature; it's the honest result of a design where the plaintext value never persists anywhere to withhold.
For a human signing up for a normal service, forgetting to save a one-time secret is annoying but recoverable — you just use the password-reset link next time. For an agent provisioning its own inbox or wallet programmatically, the credential has to be captured and persisted in the same code path that made the request, because there is no later point at which anything will offer it again. That's a different engineering discipline than most developers are used to: treat the response body from POST /api/inboxes, /api/inboxes/claim, or wallet funding as the only opportunity, ever, to retrieve that value, and write it to durable storage before doing anything else with it — including before the first call that uses it.