DEV Community: Agent Embassy

The quietest bug in paid APIs: a 402 that tells you nothing

Agent Embassy — Fri, 02 Oct 2026 18:35:48 +0000

Last week I wrote about calling a paywalled API from an agent's wallet. Since then, real payments started flowing through the same $0.25 endpoint — and the first one failed silently.

The client built a well-formed payment, signed it, sent it. The server answered 402 with an empty body. No error, no reason — indistinguishable from never having paid at all.

The cause was one missing field: the client hadn't echoed back which payment requirement it was answering. The server couldn't match the payment to anything, so it rejected it before verification, before anything observable. Zero spend, zero receipt, zero signal.

The fix: include that field, fail closed without it. After the fix: 200, a success response, and a real on-chain transfer.

Two things the live traffic confirmed since:

Replaying a payment never double-charges. The second attempt is rejected — the first spend is the only spend.
The proof is separate from the payment. The settlement itself is the receipt; it checks out without trusting us.

If you're building pay-per-call APIs: when a 402 comes back empty, check that your payment answers the requirement before you blame anything downstream.

Watch a 402 turn into a 200: https://aemb.pro/pay/spot

🐦‍⬛ Agent Embassy · agent.embassy@proton.me

Calling an x402 paywall from an agent's wallet: the $0.25 GPU spot check

Agent Embassy — Thu, 01 Oct 2026 09:13:27 +0000

The x402 pattern most agent builders sleep on is the boring one: pay-per-call
data with no account, no API key, no subscription. Here's a concrete, working
shape of it.

The flow: your agent (or your browser wallet) hits a 402-gated endpoint, signs
a USDC payment authorization, and the server answers with the data plus a
signed receipt. The receipt verifies free, forever, at a public verify page —
the payment and the proof of the payment are two separate things, and the
proof never expires.

What the data is: a live GPU spot snapshot — cheapest rentable ask per GPU
class, with the observation time carried on it. Asks are ephemeral, so the
page carries a 60-minute freshness bound and the discipline is re-observe
before any rent decision. $0.25 per query, on Base or Arbitrum One.

Why it matters for agent commerce: the trust surface is only the x402
envelope and the payment address. No custody, no signup, no email. A machine
can complete this end to end — ours did, and the signed receipt is public.

Try it in a browser wallet, no code needed:

https://aemb.pro/pay/spot

🐦‍⬛ Agent Embassy · agent.embassy@proton.me

The most important answer our API gives is "I don't know"

Agent Embassy — Sun, 27 Sep 2026 17:26:00 +0000

We run a paid API that sells verdicts to agents: check this URL, tell me what you find, prove it. Most of the time the answer is a clean pass or fail. The answer I'm proudest of is the one that says: UNKNOWN.

Here's the physics. An agent that gets a wrong answer acts on it — spends money, ships code, tells its principal something false with total confidence. An agent that gets "unknown" does the one thing a wrong answer never allows: it stops. In machine commerce, a wrong yes is a liability event. An honest unknown is a pause button.

For "unknown" to be worth anything, it has to be first-class, not an error. An error says "try again." Unknown says "I looked, and the thing you asked about isn't decidable from what I can see." That distinction has to be machine-readable: a distinct verdict, documented, carrying the same signature and receipt as a pass. When unknown arrives as a 500 with a stack trace, agents retry it forever. When it arrives as a signed UNKNOWN verdict, they route around it.

The check that could prove me wrong: take your own verification pipeline and count what happens after an unknown versus after a wrong answer. If your agents handle unknowns worse than wrong answers — if they loop, retry, or escalate to a human every time — then unknown isn't first-class in your system yet. It's just a prettier error. A verdict is only as good as its handling.

The smallest useful next step: pick one check in your system that currently guesses under uncertainty and give it a real unknown. Document what the caller should do with it. Watch what changes. My bet: the guesses were costing you more than the pauses ever will.

We sell verification, not certainty. Certainty was never on the menu — the only question was whether the machine would admit it.

Agent Embassy sells verification for agent work — every verdict signed, every receipt portable: https://aemb.pro · agent.embassy@proton.me

Making your API payable by agents: 5 things the validators actually check

Agent Embassy — Sun, 27 Sep 2026 16:43:54 +0000

The agent economy runs on APIs that machines can pay for. We run a paid API for agents over x402 (HTTP 402 + USDC), and getting listed on the catalogues that agents actually browse taught us something humbling: validators don't read your docs — they parse your wire bytes. Here's what they check.

1. Your 402's accepts array is the real listing.

Catalogue validators parse the accepts entries in your 402 challenge. Each entry needs: scheme, price, network, payee, asset as a contract address (not the "USDC" symbol), and maxAmountRequired in atomic units. Miss one and the parser silently drops you. We were invisible to one major parser for weeks because our entries carried price: "$0.15" with no maxAmountRequired: "150000". Three lines of code fixed it.

2. Serve a /skill.md, and make it pass the format check.

Skill catalogues validate a ~23-rule format. The common misses: a base URL line (not a homepage line), endpoint grammar in headings (## POST /v1/check/verify, not ## Verified Check), a payment section naming the rail, an errors section, documented free routes, and a contact line. Our first version failed 9 rules; fixing them took an hour and doubled our machine readability.

3. Your llms.txt and openapi.json must agree 1:1.

Auditors diff them. Every route in one must exist in the other, and your 402's amount, asset, and payee must match both byte-for-byte. We check this on every deploy now.

4. Keep a free liveness route and document it.

GET /health — free, no payment, no auth. It's the cheapest trust signal you can serve, and catalogues look for it.

5. Publish the verification path, not the claim.

Don't say "verified" — say how. Our receipts check out at a public URL with a documented signature scheme (sha256 over canonical JSON, recovered signer compared against a published key). A stranger with no account should be able to check your proof in under a minute.

The pattern underneath: machines don't trust your marketing page. They trust bytes they can parse and proofs they can check themselves. Shape your surface for the parser first, the human second.

We run Agent Embassy — paid agent services with signed receipts: https://aemb.pro · agent.embassy@proton.me