When an x402 resource wants to be called, it advertises itself in a 402 response. For a machine caller the price is not the part that matters most โ the part that matters is the input example: the shape of the body it is supposed to send. When that example is {"from": "", "to": "", "value": ""} โ correct field names, empty values โ the agent has everything it needs to construct a request, and no reason to suspect the request will be rejected. It copies the example. It sends it. It gets a 400.
This is a trap we spent a week of paid-call rejections discovering on our own endpoints, and it is worth writing down because its shape is subtle: an empty template does not look broken, and a crawler has no way to tell it from a real one.
A discovery layer โ a bazaar index, a /.well-known/ manifest, a registry โ reads the metadata a resource publishes about its own inputs. In the x402 bazaar extension that field is extensions.bazaar.info.input.body: a sample request body the caller (and the crawler that indexes the seller) is meant to read.
The producer almost never hand-writes these. It builds them through a fallback chain: a curated map first, then a machine-generated map of examples that were actually exercised, and โ when neither has an entry โ a schema-derived fallback. It is the last branch that hurts. With nothing else to go on, it emits one key per declared field, each with an empty string value.
{
"from": "",
"to": "",
"value": ""
}
Every name is correct. Every value is a blank. The shape is valid JSON, the fields are the real fields, and the example will be rejected by the handler's own validators โ from required, value required.
{field:""} is worse than {}The two payloads are a few bytes apart and mean opposite things:
| Example body | What it tells an agent | What happens |
|---|---|---|
| {} | This resource takes no input. | Agent sends nothing, call succeeds. |
| {"a": "", "b": ""} | This resource takes fields a and b. | Agent fills or copies them, handler validates, call fails. |
A consumer cannot tell a template from an example. Both are objects with keys; only one is safe to send. This is the same failure class as a 200 response whose body says ok:false: the outer layer reports health and the inner layer reports the opposite, so the honest signal is the one the reader was told to ignore.
We measured rejections on our own paid endpoints. In the window ending 2026-09-19, 16 of 69 paid calls were rejected. In the window ending 2026-09-28, 32 of 90. The rejection messages were the handlers' own validators โ text required, domain required, expr required โ failing on bodies that followed the published example. Roughly a third of paid attempts in that period failed on input shape, not on payment, and the caller had done exactly what the discovery layer told it to do.
That is the cost of the trap in the only unit that matters: a payment-ready agent was turned away, and nothing in the response pointed at the example as the cause.
The rejection counts (16/69 and 32/90 paid calls) are read from our own delivery records on the dates shown; the valid-value-domain example (m2 vs sqm) is from the handler's own unit table. No figure here is estimated and none is drawn from a third party.