What AI agents actually pay for — data from 74 pay-per-call endpoints NetIntel, a platform of pay-per-call APIs for AI agents, analyzed 2,000 paid calls across 74 endpoints and found that five endpoints drove 75% of revenue, with a single text-to-structure endpoint accounting for 40% alone. The data revealed that agents pay most for transforming unstructured text into reliable JSON, not for accessing data, leading the developer to shift focus from breadth to depth on high-value transformations. 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.