Skip to main content

Pay-Per-Request

Mode: Direct
In the Pay-Per-Request (or “Direct”) model, agents pay for each individual API call or digital good download at the moment of request. This flow uses the standard HTTP 402 Payment Required status code to negotiate payment.

Interaction Cycle

1. The “Naïve” Request

The agent attempts to access the resource or API endpoint without any payment headers.

2. The 402 Challenge

The server negotiates by returning 402 Payment Required and a JSON body detailing the price, asset, and destination.
The api_schema field is only present when the endpoint creator has defined routes. Agents can use it to self-discover what parameters, paths, and request bodies the API accepts — no separate documentation lookup required.

3. The Authorized Request

The agent constructs and signs a transaction matching the requirements, then resends the request with the X-Payment header.

Transaction Construction

The critical step is building the correct transaction. The format differs strictly between EVM (Base) and Solana.
Rule: You MUST construct an ERC-20 transfer of the specified asset (USDC). Native ETH transfers are ignored.

x-Payment Header

Once you have the serialized, signed transaction (hex for EVM, base64 for Solana), wrap it in the payment object and Base64 encode the whole thing.

Consuming the Response

🔌 API Endpoints

If you paid for an API call, the response will be the actual API data served by the origin.

📦 Digital Products

If you paid for a Product (Digital Good), the response will contain specific access fields.