A single call to POST /api/inboxes/{slug}/send with a drafted brief looks like one HTTP round trip from the outside. Underneath, several distinct things happen in a fixed order, and understanding that order explains a lot of the API's other behavior — why a bad brief never gets charged, why drafting-disabled inboxes reject a brief before anything expensive runs, and why the response comes back before delivery is final.
The request needs Content-Type: application/json — get that wrong and the call fails with 415 before anything else is inspected, including before the payment gate. Assuming that passes, the body is checked against the expected shape: a recipient, and either a purpose (drafted) or a subject/body pair (raw).
If the request includes a purpose, the inbox is checked for whether AI drafting is enabled. If it isn't — the inbox was provisioned with ai_drafting_enabled: false — the call fails here with a 422. This check happens before payment and before any drafting attempt; a purpose sent to a non-drafting inbox never reaches a model. See disabling AI drafting for why that inbox-level setting exists and drafted vs raw email for the two shapes this step is distinguishing between.
Beyond the shape, individual fields are checked — a missing or malformed recipient, a purpose over the 2000-character limit, and similar. Any failure here is a 422, and critically, this happens before the payment gate. See why outbound email should never be free for the pricing side and why DimeBox never charges for a failed call for why that ordering matters: a request that was never going to succeed shouldn't cost anything to find that out.
Once the request has passed validation, the route checks for a valid payment — a signed PAYMENT-SIGNATURE header verified via x402's exact scheme, or a valid wallet bearer token. No payment attached yet means a 402 response describing the price, network, and asset to pay with; see the exact scheme explained for what's actually inside that 402. Only once a valid payment is present does the route proceed.
For a purpose-based brief on a drafting-enabled inbox, this is where the brief is turned into a subject and body. Raw-mode requests skip this step entirely — there's nothing to draft when the exact text was already supplied.
Settlement happens based on the response status, not on anything downstream of it. If everything up to this point produced a response under 400, the payment settles now. A failure at any earlier step never reaches this point, which is exactly why those failures are free.
The message is handed to a background queue, and the HTTP response returns 202 Accepted — before SMTP delivery to the outbound relay has actually been attempted. See queued delivery explained for what happens from here, including how to check the final sent/failed status.
Every expensive or chargeable step — drafting, payment settlement — sits behind every validation check that's free to run. That ordering is what makes it true that a malformed request, a disabled-drafting inbox rejecting a brief, or a bad recipient address never costs the caller anything, no matter how far into the request shape the mistake was. For a runnable version of this whole sequence in Node or Python, see the API quickstart.
ai_drafting_enabled check (only if purpose is present) — free.402 appears if nothing's attached yet.purpose-based brief on a drafting-enabled inbox.Most confusion about DimeBox's behavior — "why wasn't I charged for that bad request," "why did my purpose get rejected before anything drafted," "why does the response come back before the email is actually sent" — traces back to not knowing this order exists. Once the sequence is explicit, each of those becomes the expected behavior rather than a surprise. Why every paid DimeBox route is wrapped in the same payment gate covers how this same ordering generalizes across every other priced endpoint, not just drafting and sending.
The full request and response shapes for each step — including every status code a caller can get back — are also captured in DimeBox's OpenAPI spec. Using the DimeBox OpenAPI spec to generate a typed client covers turning that spec into a client that encodes this sequence in its types, rather than re-deriving it by hand from documentation.