Skip to main content
This page is for developers who already sell an API over x402 on another network and want agents on Celo to pay for it too. The existing network keeps working: you add offers for Celo to the same route, point those offers at the Celo facilitator, and check the result with one command. Buyers pay in stablecoins and need no CELO, and the facilitator pays the gas.

Prerequisites

  • A resource server built on the x402 v2 packages, on Node.js 20 or later: @x402/express (or @x402/hono), @x402/core and @x402/evm. This page was tested with @x402/express, @x402/core and @x402/evm 2.29.0 and express 5.3.0. If you run x402 v1, see the network names under Troubleshooting.
  • A wallet address that can receive funds on Celo. An EOA works as is. A smart contract wallet only works if it is deployed at that address on Celo.
  • A Celo facilitator API key, set as X402_API_KEY. Create one on the dashboard. Without it the 402 still works, and /settle fails with 401.

How it works

A route’s accepts list can name more than one network. The buyer picks the offer it can pay and signs for that token. The resource server takes several facilitators and, for each network, uses the first one in the list that supports it. Put the Celo facilitator first: some facilitators also support Celo, and listed first they would take the Celo payments. Every other network stays with the facilitator you use today. Each token signs with its own EIP-712 domain, so an offer has to carry the extra.name and extra.version of that token on Celo. These values can differ between networks for the same token.

Add Celo to a route

The block below sells one route on Base and on Celo. The Celo offers cover USDC, USDT and USA₮, all with 6 decimals. Accept all three: wallets funded from the USA₮ faucet hold only USA₮, and a seller that does not offer it cannot sell to them.
To accept a local-currency stablecoin as well, follow Pay with Permit2 tokens. Those tokens use another transfer method and most use 18 decimals, so the onCelo helper above does not fit them.

Check the endpoint

Start the server and quote the route with the Buy CLI. It reads the 402 the way a paying agent does and tells you whether each Celo offer can be paid. It needs no wallet and signs nothing.
The USA₮ offer reports payable as yes. Abridged output:
The count shows 3 offers because the command reads the Celo offers only. Repeat with --token USDC and --token USDT. A yes means the offer matches the network, token and scheme Buy pays with. It does not prove settlement, so make one real payment before you announce the endpoint.

Keep an upstream API key on the server

Many paid endpoints wrap an API that the seller pays for. The buyer pays you over x402 and never sees the upstream key. This handler replaces the /rates handler in the example above:
  • Store the key in the environment or a secret store. Never put it in the 402, in the response, in logs, or in the route description.
  • Return an error status when the upstream fails. The middleware verifies the payment, runs your handler, and settles only if the handler answers with a status below 400. A 502 here means the buyer is not charged. If you return 200 with an error in the body, the buyer pays for it.
  • Price above the upstream cost. Your handler runs before settlement, so a payment that fails at /settle still costs you the upstream call. Include that in your margin, along with the settlement fee.
  • Cache where the data allows it. FX rates cached for 30 to 60 seconds cut upstream calls and protect your rate limit. State the cache time in the description, so an agent knows how fresh the data is.
  • Check that the upstream allows resale. Read its terms before you sell its data, including free and public APIs. Some do not allow commercial use.

Troubleshooting

Resources