Choose bounded operations for pay-per-request access
The design decision is which operations are safe for a one-off payment. Provider and lab search can be suitable because they use public catalog data. Account administration, wearable OAuth, export, deletion, and private share links require durable authority and explicit account credentials.
Implement the 402, payment, retry, and settlement flow
In an x402 flow, an agent makes a request without credentials, reads the payment requirements from the 402 response, selects an accepted network, signs a payment payload, retries with the payment signature, and reads settlement details on success.
Bind any resulting workspace to the verified payer identity and keep the authorization boundary strict. A wallet that paid for an analysis should not be able to read another person's sources, results, or dashboard simply by knowing an ID.
A safe route-selection framework
Score each route for data sensitivity, authority duration, reversibility, cost, and ownership proof. Public provider search has low personal-data risk. A wallet-owned analysis can work when ownership and storage are clearly defined. Account administration, OAuth connections, broad exports, and deletion require durable identity and explicit approval.
Publish price, network, asset, input schema, output schema, and privacy behavior before the payment attempt. An agent should know exactly what it will buy and what data the call will create.
Operational details that prevent duplicate charges
The client requests the resource, receives 402 requirements, signs a supported payment, and retries. The server verifies the payload, fulfills the operation, and settles according to the chosen scheme. Record payment identifiers with the resulting resource.
Write calls need an idempotency key tied to the intended operation. A network retry should return the existing result. Define behavior for fulfillment failure, settlement failure, expired requirements, unsupported networks, and changed prices.
- Price and accepted networks
- Input and output schema
- Idempotency requirement
- Payment and result linkage
- Refund or failure policy
x402 health route release gate
- The route has an explicit sensitivity and ownership review
- Discovery states price, network, schema, and privacy behavior
- Retries cannot duplicate work or charges
- Wallet signing material never reaches the service
- Payment receipts link to result identifiers
- Private account authority still requires scoped authentication
Offer priced discovery beside account-based access
WellNizz supports optional x402 v2 USDC payment on selected discovery, import, analysis, ancestry, action-plan, dashboard, and query routes. Its live x402 manifest declares networks, routes, prices, schemas, and examples; API keys remain the better choice for sustained use.
Keep personal authority behind explicit credentials
Payment is not consent. Do not expose private health data merely because a request has settled, and never put a signing key or sensitive data into a client-side demo.
Editorial sources
Read the primary guidance
These sources support the technical and health boundaries in this article. Provider prices, availability, and product terms should always be checked at the provider before purchase.
- How x402 WorksCoinbase Developer Documentation
- HTTP 402Coinbase Developer Documentation
- Security Best PracticesModel Context Protocol
Questions, answered
FAQ
What happens after an x402 402 response?
The client reads the payment requirements, signs the required payment payload, retries with the payment signature, and receives the result if the server verifies and settles the payment.
Can x402 replace all health API authentication?
No. It can suit selected pay-per-request routes, but durable or consequential account actions need stronger, explicit authorization.