Introducing x402 support: 10x more tools for autonomous agents

The value of AI agents is proportional to the size of tasks they can handle without human input. The longer and more complex the job, the more valuable an agent becomes. And to complete ever-longer jobs, agents will need a budget to autonomously discover and pay for the tools that they need on their own, without human-in-the-loop approvals. AI agents can call tools, but paying for those tools is still awkward.

The bottleneck isn't the API key itself; it's the human workflow around it: creating accounts, attaching billing, issuing and storing credentials, rotating secrets, and wiring them into the runtime environment. Agentic payments are an emerging answer to this, and the x402 protocol is the most promising implementation (based on real transaction volume).

With x402, the server can declare a payment requirement at request time, and the client can satisfy it automatically. Originally built by Coinbase and now an open source protocol governed under the Linux Foundation, x402 pairs naturally with the Model Context Protocol (MCP): a tool-using client can inspect MCP tool metadata, detect a payment requirement, authorize a supported payment, and retry the call automatically.

Until now, autonomous agents could buy services from a pool of roughly 2,000 endpoints available on x402. As of today, we're bringing more than 20,000 Actors from our marketplace of web automation tools into the x402 ecosystem. That's roughly 10x more tools than the protocol had before. In practice, this means an agent can pay for Apify web data and automation tools using USDC on the Base blockchain (with support for more protocols and stablecoins coming soon) instead of relying on a pre-provisioned API key.

Paying for Actors over x402

Basically, any Apify Actor can be paid for and run in as little as a single HTTP request. Your agent calls the Actor API endpoint, gets back an HTTP 402 with the available payment schemes and price. The agent's wallet signs the payment, and the Actor runs. The whole exchange happens at the HTTP layer, exactly as the protocol intends.

The easiest way to get started is to use Coinbase's Agentic Wallet CLI that handles the payment authorization in an agent-native way. It reads the 402 challenge and signs with its on-chain wallet, so the agent can execute the Actor run and retrieve data. It works best in agent runtimes that can execute shell commands and persist local state (such as Claude Code, Codex, Droid, OpenCode, or other coding agents).

Install the drop-in agent skill once, then just ask your coding agent for the data you want. It handles the wallet, the x402 payment, and the Actor run.

# Give your agent a Coinbase wallet
npx awal auth login you@email.com
npx awal auth verify <code-from-email>   # the wallet is created on first auth
npx awal show                             # fund it with USDC on Base via Coinbase Onramp
# Alternatively you can use npx awal address to view wallet funding address and then npx awal balance to check the wallet balance

# Install the "Get started" skill to use `awal` CLI
npx skills add apify/awesome-skills --skill apify-x402-agentic-wallet

# Ask your agent
Use apify/instagram-profile-scraper to get the 3 latest posts from "natgeo", paying over x402 with USDC.

Enabling x402 payments in MCP

To support the agentic payments workflow, we've also added x402 support directly to mcpc - a universal CLI client for MCP developed by Apify. mcpc is a CLI tool that maps MCP operations into commands that are intuitive for both humans and agents. It's also one of the first MCP clients to add support for x402, so agents can send payments to compatible MCP servers.

After the initial setup and wallet funding, the agent can pay for supported tool calls without per-service API key provisioning. For the full integration guide, see the Apify x402 docs.

Under the hood: The exact and upto settlement schemes

x402 originally only supported the exact payment scheme, which is useful for APIs with a fixed cost per request. But Apify Actors are used for batch operations, like web data collection, which can take variable time and cost. That means it's hard to know in advance how much the operation will cost. x402 now also has an upto scheme to help with this challenge, and Apify supports this, too.

The exact scheme, the only one in x402 v1, declares a fixed price up front, which is awkward for runs whose cost isn't known in advance. To support it anyway, Apify layers a prepaid-deposit and refund flow on top: the server requests a $1.00 prepaid deposit, the client signs an EIP-3009 TransferWithAuthorization, and any unused balance is refunded after the run.

The upto (allowance) scheme, from the x402 v2 specification, fits variable-cost work best, so it's the one we lead with. The client authorizes a maximum amount in the payment signature by signing a Permit2 permitWitnessTransferFrom, and the service charges only for what the run actually uses, anywhere from zero up to that ceiling. Apify starts the run and settles the real cost when it completes.

The technical workflow

Every Actor is callable at a plain REST endpoint, for example POST https://api.apify.com/v2/actors/<actor-id>/run-sync-get-dataset-items. Call it without credentials (you can signal x402 explicitly with an X-APIFY-PAYMENT-PROTOCOL: X402 header), and the server replies with 402 Payment Required. The terms come back in a base64-encoded PAYMENT-REQUIRED response header, alongside a short JSON body:

{
  "error": {
    "type": "x402-payment-required",
    "message": "x402 payment header missing. Add your PAYMENT-SIGNATURE or Apify token to proceed."
  }
}

Decoded, the PAYMENT-REQUIRED header is the payment challenge. It lists the schemes the endpoint accepts, both upto and exact, in USDC on Base (addresses shortened):

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.apify.com/v2/actors/:actorId/run-sync-get-dataset-items",
    "description": "Apify Store is the largest marketplace of tools for AI agents...",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "upto",
      "network": "eip155:8453",
      "asset": "0x8335...2913",
      "amount": "1000000",
      "payTo": "0x4aAb...DF26",
      "maxTimeoutSeconds": 18000,
      "extra": { "name": "USD Coin", "version": "2", "facilitatorAddress": "0x64cC...1f0A" }
    },
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "0x8335...2913",
      "amount": "1000000",
      "payTo": "0x4aAb...DF26",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USD Coin", "version": "2" }
    }
  ]
}

The amount: "1000000" is exactly $1.00 (USDC has 6 decimal places). The client reads the challenge, signs an authorization from the agent's wallet, and retries the same request with a PAYMENT-SIGNATURE header carrying the base64 payload. The server verifies it through the x402 facilitator, runs the Actor, and returns the dataset items.

Don't want to touch the protocol yourself? awal does all of this for you, or you can send an Apify token instead of a signature to pay from your account.

The signed PAYMENT-SIGNATURE stays valid while the prepaid balance lasts, so the agent reuses it on later calls, drawing the balance down with no new signing or on-chain settlement until it runs out.

Settlement, bookkeeping, and refunds

For the upto scheme, the client sends a payment signature with an allowance instead of a final amount. Apify starts the Actor run, and once complete, charges based on actual usage, which can range from zero up to the approved allowance.

For the exact scheme, once the transfer settles through the x402 facilitator, Apify starts the run and tracks the $1.00 as a temporary server-side balance. This is not fully on-chain metering: the user prepays a minimum, Apify tracks usage off-chain against that balance, and refunds the remainder later. That reduces chain interactions, but it introduces a trust assumption in Apify's bookkeeping. If the agent burns through the balance, the wallet automatically signs a new authorization to top it up. When the agent finishes, the remaining balance is refunded after 60 minutes with no active runs and no new paid tool calls.

A real world use case: trading signals from social data

One of the unique things Apify brings to x402 in the realm of trading is the signal that the markets miss: what are people actually saying? Price feeds and on-chain data tell you what happened and what the current price action is, but the live conversation on X and Reddit tells you why, and before it's priced in. An agent that can read both will make sharper calls than one starting at charts alone.

Hand your agent a goal like:

Pull live market data on $ETH from CoinMarketCap, find recent whale wallet movements on Etherscan, and analyze trader sentiment from the last 7 days on social media. Summarize main narratives and discussion themes and surface top 10 buy/sell insights based on the overall picture, then build an interactive HTML dashboard with this analysis.

The agent pulls live sentiment with Apify, pairs it with quantitative endpoints available from different vendors on x402, reasons over the combined picture, and acts, all settled on the same rail.

This composability of different vendor endpoints is the real win of x402. You don't have to provision each service individually. You simply state the desired outcome to the agent, and it discovers, prices, and assembles the tools to reach it autonomously.

Get started with a drop-in agent skill

Want to see this in action immediately? Give your agent the following skill: apify.it/x402-awal

It tells the agent how to use the Coinbase Agentic Wallet CLI npx awal, check its own balance, request funds only when needed, and run paid Apify Actors over x402.

List of useful resources

• Docs: https://docs.apify.com/platform/integrations/x402
• MCP CLI: https://github.com/apify/mcpc
• Coinbase Agentic Wallet: https://docs.cdp.coinbase.com/agentic-wallet/cli/welcome
• Agent skill: apify.it/x402-awal