Invoket

How an agent discovers and buys a paid API

The exact x402 mechanics an autonomous agent runs to call a paid endpoint — discover the resource, get the 402, sign the payment, settle through a facilitator, and replay.

An autonomous agent buys access to a paid API in one tight loop: discover the resource, send a request, receive 402 Payment Required with machine-readable payment options, sign one of them, have it verified and settled through a facilitator, then replay the request and get 200 with the result. No account, no API key, no session — the payment travels with the request. This article walks the mechanics step by step, with sources for each part of the protocol, and grounds them in Invoket’s own discovery surfaces. It is the how that follows the why in Why agents pay per call instead of API keys.

The loop in one line

The x402 standard defines the whole exchange as discover → 402 → pay → replay. The server answers an unpaid request with a 402 describing how to pay; the client attaches a signed payment and replays the same request; the server verifies, settles, and returns the resource. Per the x402 whitepaper and the Coinbase Developer Platform overview, that is the entire protocol — everything below is detail on each arrow.

1. Discover the resource

Before it can pay, an agent has to find the endpoint and learn what it costs. There are two complementary discovery paths, and Invoket exposes both.

By intent, through a registry. Because Invoket settles through the Coinbase CDP facilitator, every paid resource is indexed in the CDP x402 Bazaar — the registry that agent runtimes already query. The official x402 MCP server exposes a search_resources tool, so an agent finds endpoints by describing the problem (“screen an IBAN”, “validate a phone number”) rather than by knowing the vendor in advance. See For agents for the search surfaces.

By reading the origin directly. Every x402 origin can publish a machine-readable map of itself. Following RFC 8615 (the /.well-known/ convention), Invoket’s gateway answers a discovery cascade:

  • /.well-known/x402 — the manifest: a list of every paid resource URL on the origin, the bootstrap entry point for a crawler.
  • /openapi.json — the OpenAPI description: methods, parameters and response shapes for each endpoint, so an agent can build a valid request.
  • /catalog — the living catalog in Bazaar x402 format: for each resource, its method, its price and the list of accepted rails. This is the source of truth for what to call and how to pay.

The two paths converge on the same answer: the Bazaar tells an agent that a relevant endpoint exists; the catalog tells it exactly how to settle the call.

2. Send the request and read the 402

The agent calls the resource with no payment attached. The gateway answers 402 Payment Required with the payment requirements — an accepts array, one entry per rail it will take:

{
  "x402Version": 2,
  "error": "payment required",
  "resource": { "url": "https://api.invoket.com/iban/resolve?iban=…" },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<atomic amount>",
      "payTo": "<recipient>",
      "maxTimeoutSeconds": 60
    }
  ]
}

Each entry is a self-describing offer: a scheme, a network (CAIP-2), an asset, an atomic amount in the asset’s smallest unit, and a payTo recipient. The values above are placeholders on purpose — the real asset, amount and recipient are served live by the gateway, never copied into an article. The agent picks a rail it can settle and reads the price from /catalog. Probing is free: a bare request only returns the challenge, and no money moves until a valid payment is replayed.

3. Sign the payment payload

The agent selects one entry from accepts and builds a payment payload for that rail. For an exact scheme on an EVM network, the payload is an authorization the agent’s wallet signs locally — for USDC this is an EIP-3009 transferWithAuthorization, a gasless transfer the holder authorizes without broadcasting it themselves. The private key never leaves the agent; signing is the only thing it does. The signed payload is base64-encoded and carried in the PAYMENT-SIGNATURE request header on the replay (x402 spec, CDP overview).

4. Verify and settle through the facilitator

When the replay arrives, the server has to confirm the payment is valid and move the funds — without running its own blockchain node. That is the facilitator’s job. Per the x402 specification, the resource server either checks the payment itself or:

  1. POST /verify — sends the payment payload and the requirements to the facilitator, which validates the signature, amount, asset and network against the offered rail and returns a verification result.
  2. POST /settle — asks the facilitator to submit the transfer on-chain for the payload’s network and scheme.

This separation is why a seller needs no chain infrastructure: the CDP facilitator settles ERC-20 stablecoin transfers across networks such as Base and Solana on the server’s behalf. Invoket uses the CDP facilitator, which is exactly what makes its endpoints discoverable in the Bazaar in the first place.

5. Replay and receive 200

Once settlement succeeds, the server returns 200 OK with the resource in the body and a PAYMENT-RESPONSE header carrying the settlement proof (the transaction reference), base64-encoded. The agent now has both the answer it paid for and an on-chain receipt — in the same request cycle it started. You are charged only on success: a failed or unsigned request never debits the wallet.

The whole loop, against Invoket

Putting the arrows together, an agent that needs one IBAN check runs:

  1. Discover — find iban/resolve by intent in the CDP Bazaar, or read /.well-known/x402 → /openapi.json → /catalog directly.
  2. Request — GET https://api.invoket.com/iban/resolve?iban=… with no payment.
  3. 402 — read accepts, pick a rail (e.g. USDC on Base), read the price from /catalog.
  4. Sign — wallet signs the payment payload locally; attach it as PAYMENT-SIGNATURE.
  5. Settle — gateway verifies and settles via the facilitator.
  6. Replay → 200 — same request, now paid; the response body is the resolved IBAN, with the receipt in PAYMENT-RESPONSE.

In practice the client SDK collapses steps 2–6 into one wrapped fetch: the Quickstart shows the runnable probe → sign → replay code, and Payments and rails explains atomic amounts and which rails Invoket accepts. The agent writes the call once; the loop runs itself.

What stays off the page

A protocol description should not freeze the parts that move. Prices, atomic amounts, the payTo recipient and any signature are authority data: they live behind the live 402 challenge and the catalog, not in a blog post. This article describes the mechanism; the gateway settles the call. When the two disagree, the gateway is right.

Sources