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

> Source: <https://dev.to/karim_gueye_48291b6fc720c/what-ai-agents-actually-pay-for-data-from-74-pay-per-call-endpoints-23m1>
> Published: 2026-07-09 13:05:37+00:00

For the last several months I've run [NetIntel](https://netintel.dev), a platform of pay-per-call APIs settled in USDC over [x402](https://x402.org) — 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.

Roughly **2,000 paid calls** (per [x402scan](https://x402scan.com), 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.

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.

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.

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.

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.

*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.*
