Until now, every makesPDF request needed a Bearer token or a session cookie tied to a user account. That's a fine model for a developer paying a monthly bill, but it's friction for an autonomous agent that just wants to render a PDF and move on. As of today, you can pay per call with an x402 signed USDC payment instead.
What changed
Hit /api/v1/md or /api/v1/render with no auth and you'll get a 402 Payment Required advertising the price ($0.01 for markdown, $0.02 for DSL), the asset (USDC on Base mainnet), and the receiver address. Sign an EIP-3009 TransferWithAuthorization for that exact amount, retry with the signed payload in a PAYMENT-SIGNATURE header, and the route verifies + settles via the x402 facilitator before rendering. Idempotency is handled for you — the same signed payload coming back inside 5 minutes serves the cached PDF without re-settling.
The shape
Wire format is x402 V2: CAIP-2 network IDs (eip155:8453 for Base mainnet), atomic-unit amounts ("10000" = $0.01 USDC), extra: { name: "USDC", version: "2" }. Bearer-token and session callers are unaffected — same code path, same billing, same response. The paid path forces watermark-free output and rate-limits per wallet instead of per caller. Render failures mark the payment for refund; settle failures don't bill at all.
Caveats
x402 callers on /api/v1/render must use the inline-DSL body form ({ dsl, data }) — there's no stored-template ownership without a user account. If you want template persistence, you'll need a regular account; if you just want to render once and disappear, x402 is the path.
What's next
Bazaar should auto-discover the endpoints within hours. We'll be adding x402 mentions to /llms.txt, the skill file, and the OpenAPI spec next so AI agents can self-onboard from the docs. Wallet-claiming for humans (link an x402 wallet to a regular account) is on the roadmap.
Settled tx, payment row, and refund worklist all live in our D1 — we monitor render_status = 'failed' daily for manual refunds while volume is low.