What AI agents actually pay for — data from 74 pay-per-call endpoints

Karim Gueye — Thu, 09 Jul 2026 13:05:37 +0000

For the last several months I've run NetIntel, a platform of pay-per-call APIs settled in USDC over x402 — no signup, no API keys, no accounts. An agent hits an endpoint, gets a 402 Payment Required, pays a fraction of a cent, and gets structured data back. That's the whole loop.

I built a lot of endpoints. Network intelligence, domain forensics, text transforms, a long menu of things I was convinced agents would want.

Then I looked at what they actually paid for. The answer wasn't what I expected, and it changed how I build. Here's the data, with the caveats up front so nobody has to dig for them.

The setup

Roughly 2,000 paid calls (per x402scan, the public x402 analytics tracker) across 74 live endpoints, real USDC on Base, over a period of months. This is one platform's data in a young ecosystem — see the caveats at the bottom before you extrapolate. But the shape of it was clear enough that I stopped treating it as noise.

Finding 1: revenue is absurdly concentrated

Five endpoints drove 75% of all revenue. One of them — a text-to-structure endpoint that takes messy input and returns strict typed JSON — was 40% by itself.

The remaining ~69 endpoints split what was left, and most of them earned close to nothing. Not "underperformed" — nothing. I had spent weeks building endpoints that, in production, no agent ever paid for twice.

If you've built for agents, sit with that ratio. I had assumed a broad menu was an asset: more surface area, more ways to get discovered, more shots on goal. In practice the breadth was dead weight. The menu didn't compound; five items carried it and the rest were maintenance cost.

Finding 2: agents pay to fix text, not for exotic data

The thing that dominated wasn't clever data. It was transformation — turning unstructured text into a schema the agent could act on.

That reframed the whole product for me. An agent's expensive problem isn't accessing data; it's trusting the shape of what it already has. A blob of text it has to parse itself is a liability — it costs tokens, it costs a fragile parsing step, it costs an entire branch of "what if this comes back malformed." Selling it a guaranteed clean structure removes that liability in one call.

The most valuable thing I sell isn't information. It's the removal of the agent's own uncertainty. That's a different business than "API for X data," and I only saw it by looking at the receipts.

Finding 3: volume is not value

The endpoint agents called most often was not the endpoint that made the most money. Not close.

Spend tracked the value of the task completed, not the frequency of the call. High-frequency, low-stakes lookups generated a rounding error. Lower-frequency, high-value transformations generated the revenue. If I'd optimized for call volume — the metric that's easiest to see on a dashboard — I'd have doubled down on exactly the wrong endpoints.

What I changed

I killed the breadth instinct. I stopped shipping speculative endpoints to "see if they stick," because now I know what sticking looks like and most of them never will. The plan is depth on the few categories that actually pay: make the winners faster, cheaper, more reliable, and harder to leave, rather than adding a 75th thing nobody asked for.

Breadth felt like progress because building is satisfying and each new endpoint looked like an asset on the menu. The data says it was mostly a distraction I could afford to build only because it was cheap to build. That's not a strategy — it's a hobby that happens to be adjacent to a business.

Caveats (read these before you quote me)

Small sample. ~2,000 paid calls is enough to see a shape, not enough to bank a law. Treat this as a directional signal from one operator, not a benchmark.
One platform, one catalog. My menu is skewed toward network/domain intelligence and text tools. Your mix would surface different winners. The concentration pattern may generalize; the specific winner probably won't.
Early ecosystem. A meaningful share of x402 traffic today is experimental and non-commercial. Some of what looks like demand is people kicking tires. I've tried to reason about paid, repeat behavior rather than one-off test calls, but the noise floor is real.
Survivorship in the framing. "The other 69 were a distraction" is the lesson I drew, but a few of those may just be early, or badly discovered, rather than genuinely unwanted. I'm betting they're dead weight; I could be wrong about the margins. None of that changes the headline: in production, agent spend was extreme in its concentration, it favored transformation over raw data, and it ignored call volume entirely. If you're building for this market, I'd plan for a few things carrying everything — and figure out which few as fast as you can.

I run NetIntel — pay-per-call network and structured-data intelligence for agents over x402. If you're building agents and want to compare notes on what your traffic actually pays for, I'm genuinely interested; that's the data I wish more people published.

Built NetIntel: 64 network-intelligence + data tools for AI agents

Karim Gueye — Sun, 21 Jun 2026 23:45:16 +0000

Built NetIntel: 64 network-intelligence + data tools for AI agents.

DNS, SSL, WHOIS, email security, OSINT, structured data extraction — all pay-per-call via x402 on Base. No API keys, no signup. Agents just pay a fraction of a cent and go.

Live now 👇
github.com/kjgueye/netintel-api

@CoinbaseDev @x402

DEV Community: Karim Gueye