What x402 and MPP make possible for agent builders.

A research agent walks into eight paid data providers. It pulls a price feed from one, a sanctions list from another, a satellite image from a third, a sentiment score from a fourth. Each call costs a fraction of a cent. Each call returns a receipt. The agent never signed a subscription, never put a card on file, and never gave the providers a contract. It just paid, per call, and went on with its day.

This is not a thought experiment. It's what already happens, every day, across the catalog of x402 services. The thing that took a quarter-century to arrive — a usable HTTP-native payment primitive — is now here, and it changes what you can build.

The use case before the spec

Forget the protocol for a second. The thing that's new is the unit of work.

The standard model for paid APIs has been: pick a tier, sign a contract, put a card on file, get a budget review every quarter. The tier sets a ceiling on calls per month. The card means a finance team has to approve every new vendor. The contract means a procurement cycle that's measured in weeks, not minutes.

This works for traditional software, where the buyer is a human team, the call volume is roughly predictable, and the relationship is durable. It does not work for an agent.

Agents have the opposite shape:

• Bursty by design. A planning step might fan out to twelve providers, then call none of them again for a week.
• Discovered, not contracted. The agent finds the right provider mid-task, not via a procurement cycle.
• Ephemeral. The agent that needed the call this morning may not exist this afternoon.

What works for an agent is a unit of work where the agent shows up, asks for the data, pays for the data, gets the data, and leaves. No relationship. No contract. No card. Just an HTTP request and a payment.

That unit of work is what x402 is.

How x402 actually works

The HTTP spec reserved status code 402 for "Payment Required" in 1997 and then never specified what payment meant. For 25 years it was an unused slot. Coinbase and a small group of crypto-native developers filled it in over the last year and a half: when a server returns 402 Payment Required, it includes a structured body describing how much the call costs, what asset it accepts, and where to send it. The client signs an off-chain authorization (ERC-3009 transferWithAuthorization for USDC on Base, in the common case), retries the request with the signed authorization in a header, and the server settles the payment and returns the data.

Two HTTP round-trips. Settlement in seconds. No accounts, no subscriptions, no API keys.

From the agent's side, it's still a fetch(). From the developer's side, you don't need to write the protocol-handling code yourself. The Canopy SDK turns it into one method:

import { Canopy } from "@canopy-ai/sdk";

const canopy = new Canopy({
  apiKey: process.env.CANOPY_API_KEY!,
  agentId: process.env.CANOPY_AGENT_ID!,
});

const response = await canopy.fetch("https://api.example.com/quote?symbol=ETH");
const data = await response.json();

canopy.fetch() is fetch() plus payment when the server returns a 402. If the response is 200, you get the response. If it's 402, the SDK reads the offer, runs it through your agent's policy (cap, allowlist, approval threshold), signs the authorization if the policy allows, retries the request, and returns you the response. To the calling code, paying and not-paying look the same.

Why this matters for finance teams

A reasonable question, especially from someone who hasn't bought infrastructure this way before: "isn't pay-per-call worse than a flat monthly tier?"

The honest answer is sometimes yes, often no — but it's the kind of cost that's different, not just the amount.

• You see what each call costs. A $200/month enterprise tier hides which feature on which day used the budget. Per-call billing gives you a receipt for every request, attributed to the agent that made it. Cost-of-goods-sold becomes a real number, not a guess.
• Spend tracks usage. If the agent isn't running, the spend isn't there. There's no shelfware tier you keep paying for through a quiet quarter.
• You can gate spend at the call level. This is the part that turns "pay-per-call" from a billing strategy into a control plane. With Canopy's policy engine sitting in front of every canopy.fetch(), the cap, allowlist, and approval threshold apply per call. Limits are real, not aspirational.

The first quarter of running per-call infrastructure looks weird on a P&L because the line items are smaller and there are more of them. The second quarter, when you can actually attribute spend to specific agent runs and specific outcomes, looks like a serious upgrade.

What's already paid this way

This is not a future-tense post. Every category of API an agent might want to call has at least some x402-native option live today:

• Market data and sentiment — price feeds, on-chain analytics, social sentiment, news.
• Search and scraping — search APIs, page-content fetch, structured-data extraction.
• People and companies — B2B enrichment APIs that used to require enterprise contracts.
• Maps, weather, travel — flight data, geo APIs, weather feeds.
• AI inference — LLMs, image generation, transcription, embeddings.
• Compute — sandboxed code execution, Wolfram-style symbolic compute.

The catalog is growing weekly as more providers ship x402 manifests. We index the ones we've verified at /discover — every entry shows what protocol it speaks, the category it sits in, and a link to the provider's docs.

What's coming

The most useful thing to know about x402 is that it isn't going to be the only protocol that looks like this.

Stripe shipped Machine Payments earlier this year — same wire shape (HTTP 402 + signed stablecoin transfer), but with Stripe acting as the facilitator. Coinbase and Google have a separate effort, AP2 (Agent Payments Protocol), that takes a mandate-based approach: the agent's user pre-signs a mandate, and the agent operates within it. Lightning has L402, a Bitcoin-native cousin.

We expect the family to grow before it consolidates, and the family to converge on a single shape — HTTP 402 for the handshake, signed stablecoin transfers for the settlement. Canopy abstracts the rail behind a single canopy.fetch() so the agents you build today keep working as more rails come online.

If you'd told a developer in 2010 that 402 would become a primary method for paying for APIs, they would have laughed. The thing that changed is who the buyer is. APIs are now bought by software, not by procurement. The protocol caught up.

Browse the catalog of x402 services, or npx create-canopy-agent to start a project that uses one.