HTTP has had a status code reserved for payment since the earliest web standards: 402 Payment Required. For roughly thirty years almost no server used it for anything, because nothing on the other end knew how to complete a payment inside an HTTP request. x402 is the protocol that finally gives that status code a job. It defines exactly what a server puts in a 402 response and exactly what a client sends back to prove it paid, so an API can charge per call without an account, a stored card, or a human clicking "approve."
DimeBox runs its entire paid surface on x402: drafting an email, sending from an inbox, delivering a message with priority. This post walks through the mechanism itself — what actually goes over the wire — so the rest of the blog and the API reference make sense without hand-waving.
Every x402-gated DimeBox route behaves the same way, independent of what the route does once you're past the gate:
402 with a PAYMENT-REQUIRED header describing the price, the asset, and the network to pay on.PAYMENT-SIGNATURE header attached.400. A route that fails for any reason never gets paid.In practice, against DimeBox's drafting endpoint:
# 1. Call unpaid
curl -i -X POST https://dimebox.app/api/emails/generate \
-H 'Content-Type: application/json' \
-d '{"recipient":"[email protected]","purpose":"follow up after demo"}'
# -> HTTP/1.1 402 Payment Required
# -> PAYMENT-REQUIRED: <base64-encoded payment terms>
# 2. Sign a payment matching those terms, then retry
curl -X POST https://dimebox.app/api/emails/generate \
-H 'Content-Type: application/json' \
-H 'PAYMENT-SIGNATURE: <signed payment>' \
-d '{"recipient":"[email protected]","purpose":"follow up after demo"}'
# -> HTTP/1.1 200 OK
# -> { "email": { "subject": "...", "body": "..." }, "paid_by": "0x..." }Nothing here requires DimeBox to know who the caller is beforehand. There's no signup step that happens once and an API key that gets reused forever — every call carries its own proof of payment. See how a 402 response actually works, step by step for what's inside that PAYMENT-REQUIRED header and what a valid signature has to contain.
x402 defines more than one way to construct a valid payment (a "scheme"), but the one DimeBox and most of the current ecosystem use is called exact: the client signs an authorization for a specific USDC amount, on a specific network, that only the quoted request can redeem. The signature itself is an EIP-3009 transferWithAuthorization — a gasless transfer the recipient (DimeBox, via a facilitator) submits on the client's behalf, so the caller never needs ETH sitting around just to pay gas. Both of those mechanisms get their own posts: the exact scheme explained and what EIP-3009 actually does.
Verifying and submitting that signature is a facilitator's job, not DimeBox's own backend — see x402 facilitators explained for who does what in that handoff.
Account-based auth assumes a session: something logs in once, gets a token or a cookie, and reuses it until it expires. That model was built for a human sitting at a browser. An autonomous agent calling an API with no one watching doesn't have a session to protect, a password to remember, or a dashboard to click "upgrade plan" in. What it does have is a wallet. x402 charges that wallet exactly what the call costs, exactly when it happens, with no provisioning step beforehand. x402 vs API keys goes deeper on why that difference matters specifically for agents, rather than for a human developer integrating an SDK once and forgetting about it.
DimeBox gates four distinct actions this way, each with its own price read live from configuration rather than hardcoded into a contract: drafting an email, sending from an inbox, claiming a custom inbox name, and priority delivery into an inbox. A caller never has to guess these numbers or keep a local price list in sync — the 402 response for a given route always carries that route's current price, so a client that reads the header correctly can never drift out of sync with what it's actually charged. The API reference lists the current defaults for all four alongside the full request/response shape for each.
It isn't a subscription mechanism — there's no recurring charge implied by the protocol itself; each call is priced and paid for independently. It isn't a replacement for TLS or request signing either; x402 answers "has this call been paid for," not "is this connection secure." And it isn't specific to email or to DimeBox — it's a general-purpose pattern for pricing any HTTP endpoint per call, which is why agentic commerce as a category leans on it for more than just inboxes.
If you want to see the exchange happen against a live endpoint rather than read about it, the buyer quickstart has runnable Node and Python examples using the current x402 client libraries. For the economics of pricing by the call instead of by the month, see pay-per-call vs subscriptions.