Skip to main content
PERSONA 2 VARIANT - API PROVIDERS

Sell your API to AI agents.

AI agents cannot fill out a credit card form. They can pay you in USDC. Blockchain0x makes that one API call.

THE PAIN

Your API was designed for humans. Your callers are now agents.

The next decade of API revenue will not come from human signups. It will come from AI agents calling APIs on behalf of their users, often programmatically and without any human in the loop. Those agents cannot use your existing checkout. They cannot fill out a credit card form, cannot create an account, cannot click a confirmation email, cannot remember a password.

What they can do is read a 402 Payment Required response, parse the USDC amount and recipient out of the JSON body, pay on Base, and re-issue the call with proof of payment. That is the entire shape of agent-driven API commerce. The cost model (per-call billing in stablecoin) also fits agent usage shape much better than card-based subscriptions: cards fail at sub-$1 transactions; USDC on Base costs cents in gas; chargebacks do not happen between machines.

Blockchain0x is the bridge. List the routes you want to charge for in a pricing table and mount the x402 adapter. When an unpaid call hits a priced route, the adapter returns a 402 describing exactly what to pay. The agent pays on Base and retries with an X-Payment header; the adapter verifies it and your handler runs. You collect USDC and run your API as before. Nothing about your business logic changes; the billing layer rides alongside.

402 PAYMENT REQUIRED

The HTTP status code finally has a use.

HTTP 402 was reserved in the original spec for "future use" and never standardized. For thirty years it sat unused while the internet built per-account subscription billing on top of 200/401/403. With Coinbase's x402 protocol, 402 finally has a standard implementation: any API that needs payment-before-it-runs can return a structured 402, and any client that understands the spec can pay and retry.

YOUR API RETURNS THIS 402 BODY WHEN A CALL HAS NOT BEEN PAID
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "resource": "POST /api/expensive-operation",
  "accepts": [
    {
      "scheme": "exact-usdc",
      "network": "mainnet",
      "chainId": "eip155:8453",
      "payToAddress": "0xYourAgentWalletAddress",
      "amountWeiUsdc": "500000",
      "paymentRequestId": "pr_demo",
      "maxAgeSeconds": 60
    }
  ]
}

What the accepts[] requirement means

  • scheme - the payment scheme. exact-usdc means an exact USDC amount on an EVM chain. The client matches on this before paying.
  • network / chainId - the chain to settle on (mainnet is Base, CAIP-2 eip155:8453). A migration can quote both networks by listing two requirements in accepts.
  • payToAddress / amountWeiUsdc - the recipient wallet and the exact amount in USDC base units (500000 = 0.50 USDC, 6 decimals). The client verifies both before paying.
  • paymentRequestId - ties the payment to this quote. The adapter rejects an X-Payment that references a different paymentRequestId than the route quoted.
  • maxAgeSeconds - how fresh the payment must be. A payment older than this window is rejected and the caller must pay again.

x402 is machine-to-machine: an x402-aware client reads accepts, pays the chosen requirement on-chain, then re-issues the request with an X-Payment header that the adapter verifies. A client that does not speak x402 simply receives the 402 and gets no result, which is the correct outcome (the call was not paid). There is no hosted checkout page in this flow; the payment is settled programmatically by the caller's wallet.

ADAPTER PATTERN

One pricing table. Three languages. Same shape.

You mount one adapter and give it a pricing table keyed by METHOD plus path. It gates only the routes you list; your handler never sees an unpaid call, because when it runs the X-Payment header has already verified. The shape is identical across Python, TypeScript, and Go - the X-Payment wire format is the same, so a Go server accepts headers built by a Python client.

PYTHON (FLASK)
from flask import Flask
from blockchain0x import Client
from blockchain0x_x402.server import x402_before_request_factory, PricingEntry

sdk = Client()  # reads BLOCKCHAIN0X_API_KEY
app = Flask(__name__)

# Only routes named in the pricing table are gated.
app.before_request(x402_before_request_factory(
    sdk=sdk,
    pricing={
        "POST /api/expensive-operation": PricingEntry(
            amount_usdc="0.50",
            pay_to_address="0xYourAgentWalletAddress",
            payment_request_id="pr_demo",
        ),
    },
))

@app.route("/api/expensive-operation", methods=["POST"])
def expensive_operation():
    return run_the_work()  # only runs after X-Payment verifies
TYPESCRIPT (EXPRESS)
import express from "express";
import { createClient } from "@blockchain0x/node";
import { createX402Middleware } from "@blockchain0x/x402/server/express";

const sdk = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! });
const app = express();

// Only routes named in the pricing table are gated.
app.use(createX402Middleware({
  sdk,
  pricing: {
    "POST /api/expensive-operation": {
      amountUsdc: "0.50",
      payToAddress: "0xYourAgentWalletAddress",
      paymentRequestId: "pr_demo",
    },
  },
}));

app.post("/api/expensive-operation", async (req, res) => {
  res.json(await runTheWork());  // req.x402Payment holds the verified payment
});
GO (NET/HTTP)
import (
  "net/http"
  x402 "tosh-labs/blockchain0x-x402-go"
)

func main() {
  pricing := map[string]x402.PricingEntry{
    "POST /api/expensive-operation": {
      AmountUSDC:       "0.50",
      PayToAddress:     "0xYourAgentWalletAddress",
      PaymentRequestID: "pr_demo",
    },
  }

  // serverSdk is your Blockchain0x Go SDK client.
  h := x402.Middleware(x402.ServerOptions{Sdk: serverSdk, Pricing: pricing})(
    http.HandlerFunc(expensiveOperation))
  http.Handle("/api/expensive-operation", h)
  http.ListenAndServe(":8080", nil)
}

We ship server adapters for Express and Fastify (Node), ASGI (Starlette and FastAPI) and Flask (Python), and Go's net/http. For other frameworks, the 402 body and X-Payment header are plain HTTP that the wire helpers in @blockchain0x/x402 build and parse - hand-write the check in your stack's idiom. Ruby and JVM x402 packages are published for the client side.

VS STRIPE CHECKOUT

When to reach for each tool.

Stripe is the right tool for human checkout. Blockchain0x is the right tool for agent checkout. They solve different problems and frequently sit side by side on the same API.

DimensionBlockchain0xStripe Checkout
BuyerAny HTTP client (human or AI agent)Human at a browser
Auth required before paymentNo - first call returns 402 with the payment requirementsYes - email + card form
Settlement speed5 seconds (USDC on Base)2-7 days (card networks)
Chargeback riskNone (USDC is final)Up to 120 days of chargeback window
Per-transaction cost economicsWorks at $0.01-$0.10 per call (Base gas + our fee)Card fees make sub-$1 transactions uneconomical
RefundsManual - your code sends USDC back to the payer addressAutomated through Stripe dashboard
International supportSame wallet, any country, no extra configPer-country licensing, currency conversion, regional rules
Best forProgrammatic agent-driven API consumptionHuman-driven checkout (SaaS signup, e-commerce)

The pattern most API providers land on: keep Stripe for the human signup flow (your dashboard, your subscription product page); add Blockchain0x at the API edge for programmatic agent access. The x402 adapter only gates the routes you put in its pricing table, so your human, Stripe-authenticated routes are untouched. Point agents at the priced routes and humans at the rest, and both audiences are served by the same API code.

WHAT PLAN FITS

Pro for early traffic. Business when audit logs become a requirement.

API providers almost always start on Pro from day one: Free is read-only, and the x402 adapter needs the API access to verify and settle payments plus webhooks to track them. High-traffic APIs cross into Business territory as monthly volume climbs. See the pricing page for the exact per-agent cost and where the tiers sit.

  • Free: useful only for the dashboard and metadata exploration. Read-only, so the adapter cannot settle payments.
  • Pro: default for live API monetization. Full API access, webhooks, exports.
  • Business: when you need audit logs for compliance, or higher API rate limits.
See full pricing
FREQUENTLY ASKED

Five API-provider questions.

Can I run Stripe alongside Blockchain0x for the same API?

Yes, and many API providers do. The pattern: keep your existing Stripe-based human signup flow, and list only the agent-facing routes in the x402 pricing table. The adapter gates exactly those routes; everything not in the table (including the routes your Stripe-authenticated customers call) passes straight through, unaffected. If you want a single route to serve both, check your own API key in the handler and skip the priced path for authenticated callers. Both audiences get what they want without one path blocking the other.

What if an AI agent pays then exits before retrying the call?

The payment is still valid on-chain; it just goes unused. The agent's wallet shows a successful USDC transfer to your address. From the agent's perspective it lost the USDC; from yours, you got paid for a call that never executed. This is rare in practice (the x402 client retries immediately after paying), but if you want to be defensive you can track verified payments that never produced a completed call and send the USDC back yourself with payments.create, paying the original payer address. There is no separate refund endpoint - a refund is just a payment in the other direction.

How do I version my API and price changes?

Each entry in the pricing table is per-route, so different routes can charge different prices. For versioning, the recommended pattern is to expose v2 endpoints alongside v1 with the new prices as new pricing-table entries; clients see the new amount in their first 402 response on the v2 route and pay accordingly. Sudden price increases on stable routes are bad protocol citizenship; we recommend deprecating the old route and serving a 410 Gone that points to the new route at the new price.

What does observability look like - logs, metrics, alerts?

Every payment shows up in the Blockchain0x dashboard with the payer wallet, amount, and timestamp, and the same data arrives on your payment.received webhook so you can stream it into Datadog, Splunk, or your own logging stack. The adapter runs inside your server, so the request-level signals (which route was quoted, every 402 you returned, every X-Payment you verified) are yours to log and emit as metrics in whatever format your stack uses. Wire alerts on the obvious ones: a sudden spike in 402 responses, or a drop in the verified-payment rate.

What about regulatory questions - am I a money services business if I do this?

Probably not, but this is jurisdiction-specific and we are not your lawyers. The reason: you are receiving payment for services you provide, not transmitting money between third parties (which is the trigger for MSB status in the US). USDC is recognized as a payment-stablecoin in most jurisdictions. You do owe tax on the USD-equivalent revenue; we generate the records you need for that. If you operate in a high-volume B2B context or in a jurisdiction with strict crypto rules (Germany, Singapore for certain shapes), get specific legal advice before flipping on production traffic. We can refer you to firms that have done this work for previous customers.

Let agents pay for your API.

Add a route to the pricing table and mount the adapter. Stripe stays for humans. Both audiences served.