Small objects agents can collect, with every proof kept.

Prepared-only today. These calls are documented and implemented, but fail closed until the 81 editions are minted to the sponsor wallet, independently verified on Tezos mainnet, and the delivery budget is explicitly enabled.

1. 01 · INSPECT

   Choose an immutable offer.

   Read the catalog and pin its offer slug, FA2 token, metadata hash, price, and readiness state.

   GET /x402/collect.json
2. 02 · CHALLENGE

   Bind the Tezos recipient.

   Send a stable idempotency key. The five-minute response contains exact Micheline bytes for the recipient wallet to sign without spending tez.

   POST /api/agent-cabinet/challenge
3. 03 · QUOTE + APPROVE

   Prove first; pay second.

   Submit the wallet proof without payment. If inventory is ready, the server pins it and returns 402 terms. Obtain the agent owner's spend approval before adding a payment signature.

   POST /api/agent-cabinet/collect
4. 04 · SETTLE

   Submit the approved payment once.

   Replay the same collect request with the x402 Payment-Signature. A 202 payment-settled response is durable, but it does not yet start Tezos delivery.

   POST /api/agent-cabinet/collect
5. 05 · RESUME + VERIFY

   Follow the server until both rails settle.

   While intent.next.action says resume-delivery, replay that exact POST with the same key and body, omit the payment signature, and honor its retry delay. The payment will not be resubmitted. Once it says poll-status, poll until the exact FA2 movement has two Tezos confirmations. Stop automatic retries on either operator-review action.

   POST collect → GET status

curl -X POST https://pointcast.xyz/api/agent-cabinet/challenge \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: collect-listening-001' \
  --data '{"offer":"listening-tile-001","recipient":"tz1..."}'

curl -X POST https://pointcast.xyz/api/agent-cabinet/collect \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: collect-listening-001' \
  --data '{"offer":"listening-tile-001","recipient":"tz1...","challengeId":"acc_...","publicKey":"edpk...","signature":"edsig..."}'

The sequence is quote POST → paid POST → zero or more server-directed delivery-resume POSTs → status GET. Every POST uses the same Idempotency-Key and exact JSON body. Optional PointCast-Agent-* headers must be omitted through settlement or identify the same active registered caller on challenge and collect through settlement. An exact paid delivery replay may omit them so key expiry cannot strand the buyer. They never replace the recipient-wallet proof or authorize spending.

Payment-profile boundary. The advertised payment signature is pointcast.bubbletez-permit2-exact/v1, a facilitator-specific BubbleTez/TZAPAC Permit2 profile reviewed 2026-09-21. It uses spender 0xB6FD384A0626BfeF85f3dBaf5223Dd964684B09E and witness Witness(address to,uint256 validAfter,bytes extra). It is not the current canonical x402 Permit2 typed-data profile, whose documented proxy is 0x402085c248EeA27D92E8b30b2C58ed07f9E20001. Clients must follow the exact 402 response and must not silently substitute one profile for the other.