How to charge AI agents for API calls, one call at a time

What does it mean to charge AI agents for API calls?

To charge AI agents for API calls is to bill each request on its own, at the moment the agent makes it. No contract, no monthly invoice: the agent pays a set price, your API runs, and the agent gets the answer. The model fits agents well, because they often need one lookup or one computation and nothing more.

Any HTTP API can work this way. Weather, pricing data, a model you host, a document conversion or a file download are all single calls with a clear result. What you need is a way to collect a tiny payment before the call, prove to your server that it was paid, and keep a record both sides trust.

Why don't cards work for a pay per call API?

Card pricing has a fixed part that small charges can't absorb. Stripe's standard US online price is 2.9% + 30¢ per successful domestic card transaction.

Card-based agent checkout systems, such as the Agentic Commerce Protocol behind Instant Checkout in ChatGPT, suit buying physical goods. For a pay per call API priced in cents or fractions of a cent, the fee structure is the problem. Qatom charges no transaction fees and no gas, so the cost of a payment does not grow with its value or volume.

How does API monetization for AI agents work on Qatom?

API monetization for AI agents on Qatom follows one round trip: buyer agent, Qatom twin, seller endpoint, in one call. Here is what happens when an agent buys one call to your API.

1. The agent finds your item with catalog_search and reads its price, seller and input schema.
2. It calls agent_checkout with the item id and arguments.
3. Payment settles from the buyer's agent wallet in under one second. Above the owner's auto-approve limit, the owner approves first.
4. Qatom calls your endpoint with the declared arguments, your Authorization header and an X-Qatom-Transaction-Id header.
5. Your answer returns to the agent inside a receipt with the transaction id, and the buyer gets an emailed receipt.

Your endpoint only runs after step 3 (B2). Behind the scenes, each catalog item works through its own provider twin, which acts as a paywall in front of your HTTPS service (C21).

x402 vs a catalog: which fits your API?

x402, created by Coinbase in May 2025 and governed since April 2026 by the x402 Foundation under the Linux Foundation, revives HTTP 402 "Payment Required". Your server answers 402 with a price, the client signs a stablecoin payment and retries with an X-PAYMENT header, and a facilitator settles onchain on chains such as Base. It fits teams that want payment inside the HTTP exchange and already work with onchain wallets.

If you go this way, choose a facilitator that has adopted the fixes from the July 2026 x402 security research, settle before you serve the response, and decide how you will handle refunds, which the protocol does not cover.

Qatom settles USD-TDN between twins with no gas and no public ledger, and adds the parts around the payment: a catalog agents search, wallets with spending limits, approvals, receipts and payouts. These approaches can complement each other. The protocol comparison covers AP2, ACP and the card networks too.

How do you set up the endpoint and secret header?

To charge AI agents for API calls safely, start with the endpoint, because its answer is what the buyer's agent receives. The Worker template reads one catalog.json, validates inputs, guards the paid route and serves /llms.txt.

1. Name things once. Give each item one permanent lowercase ID and a one-sentence summary in every response.
2. Return useful errors. Every error needs a code, a plain message and a next step, for example unknown_parameter 400 or bad_value 400.
3. Test directly first. Call the endpoint yourself before testing through Qatom, since a failed call may be relayed as a generic payment error.
4. Generate the token. Run openssl rand -hex 24 on your own machine and store the result, for example with wrangler secret put QATOM_FULFILMENT_TOKEN.
5. Check it on every call. Compare the Authorization header in constant time and answer 404 when it is missing or wrong (B3).
6. Set it on each item. In Request headers & secret parameters, add Authorization as Sensitive with the value Bearer <token>, then save (B12).

Keep secrets out of the endpoint URL, since other dashboard users can see it. Never echo request headers in a response. If a token may have leaked, rotate it with a short overlap where the endpoint accepts both values (B24).

How do you define the input schema?

The schema is the contract between the agent and your API. Qatom forwards only the arguments it declares and rejects the rest (B11).

• One property per real input. Give each a description with its unit, range and default. For example, a video item takes one optional ttl_seconds input from 60 to 86400, default 3600.
• Close it. Set "additionalProperties": false.
• No free-form code. Never accept raw SQL, code or query strings; turn them into named inputs.
• Describe formats. Leave example IDs out of the schema and describe the format instead.

Paste it into the Service schema editor as {"inputSchema": {...}} and click Format. The editor confirms the tool arguments, or says the tool takes none.

How do you verify each fulfillment call?

The secret header proves a call came from Qatom. For anything expensive to serve, such as stream keys, downloads or game entries, also prove the call matches a settled sale of that item (B20).

1. Read the X-Qatom-Transaction-Id header on the incoming call.
2. Get an account token with your client credentials from /v4/account/oauth/token, on your server only (S2).
3. Call GET /v4/catalog/purchases/{transaction_id}.
4. Refuse the call if the id is unknown or belongs to another item.
5. Store the ids you have served so no sale is served twice.

Cheap reads can rely on the header alone. The OpenAPI document lists every v4 endpoint, and the developer docs cover the Payment Node SDK.

How do you set usage-based API pricing?

Usage-based API pricing here means a fixed price per call, so revenue tracks volume. Before you charge AI agents for API calls, work out what one answer costs you to produce. Prices are in USD-TDN (1 USD-TDN equals 1 USD), from 0.001 per call, with at most three decimals.

The cash-out fee is a flat $1 per bank transfer, with a 10 USD-TDN minimum, so cashing out less often keeps more of small-price revenue. Your plan also matters: Builder is free with up to 25 transactions a month, and Pro ($20/month) and Max ($300/month) are on the pricing page.

A few rules shape the price list:

• One item, one price. Tiers are separate items, and each description says what the higher tier adds.
• Add a free check. A 0-priced sibling lets an agent confirm fit before paying.
• Quantity is per copy. A buyer can add up to 20 of an item to a cart, and each copy is its own purchase with its own transaction id.
• Small prices suit wallets. Guest card checkout has a minimum of about $0.50.

Why should metering sit in the request path?

Usage-based pricing usually means counting calls and billing at the end of the month. With AI agents as customers, that leaves you carrying the risk: an agent can make thousands of calls before anyone checks the bill. Kong's talk "From Tool Calls to Revenue" at MCP Dev Summit Toronto 2026 put it simply: "a meter that cannot say no is accounting, not control."

Charging per call through Qatom puts the meter in the request path. The buyer's agent pays first, Qatom calls your endpoint with your secret header, and you check the transaction id before serving. There is no invoice to chase, and Qatom calls your endpoint only after payment settles.

How do you sell API access to AI agents once it is live?

Buy every item once through the master MCP before you tell anyone (B19). Then run catalog_search for your brand prefix and check each item's name, price and seller name (B21).

To sell API access to AI agents, be where they look. Buyers reach the catalog from any MCP client, and from the assistants and channels listed on qatom.ai. Agents read your llms.txt before calling, so link it from every item description (B4).

After launch, each item page shows its sales count and earnings. A distribution can split revenue across up to 200 payees, and cash-outs go to US or Canadian bank accounts by ACH in 2 to 5 business days.

Next steps

• Read how to monetize an MCP server if your API is already exposed as MCP tools.
• Work through the seller steps in the Capabilities Index.
• Contact the team about hosted, VPC, on-premises or air-gapped deployment.