I have been writing about API monetization since 2011. Not consistently, but in recurring waves — whenever the business reality of APIs forces itself back to the surface. Early on I was fascinated by the mechanics: resource-based versus experience-based pricing, the cost-to-value accounting framework I tried to formalize, the uncomfortable question of whether open government data could ever generate revenue without betraying its public mission. I spent a lot of time in that era trying to help government agencies — the Forest Service, the National Park Service, the Bureau of Land Management — understand that the value flowing through their APIs was real and worth naming, even if calling it “monetization” was politically untenable.
I feel that last part is worth thinking about more. The word monetization has always been a barrier in exactly the places where API value matters most. When I was pushing the Department of Agriculture to make APIs a first-class citizen in the Recreation One Stop RFP, I couldn’t walk into those rooms talking about monetizing access to campsite reservations or national park geospatial data. The value was real — millions of families planning camping trips, small businesses building itinerary tools, agencies making operations data portable and interoperable across the Forest Service, Army Corps of Engineers, Bureau of Reclamation, and a dozen other federal partners — but the word “monetization” shut the conversation down before it started.
I have been using public lands as an analogy for public data APIs for years because of this. A national park isn’t valuable primarily because it generates revenue. It’s valuable because of what it makes possible: recreation, conservation, ecological research, local economies, a shared sense of what this country is. The value is real, diverse, and distributed across many stakeholders — not all of whom are in a financial relationship with the park service. The same is true of a well-designed public data API. Calling the question “how do we monetize this?” misframes what’s actually happening, which is an exchange of value — in many different directions, not all of them financial.
I want to start calling this what it is: API value exchange.
AI has given me renewed energy for this framing. Not because AI makes APIs more commercial, even though it often does. It is because AI has made the volume and velocity of API consumption so undeniable that even organizations that spent a decade ignoring the question can’t look away anymore. As I have been writing lately, there is really only API consumption — everything else is scaffolding in service of getting value from one system into another. AI agents are now doing this at a scale and speed that exposes every gap in how organizations have been thinking about the value flowing through their APIs. The question is no longer whether to think about API value exchange. It is whether you have built the visibility to see it happening.
The renewal I’m feeling is not about AI APIs specifically — the market for those is being worked out loudly and publicly enough. What interests me is how AI-driven consumption is forcing organizations to think carefully about their internal APIs, their partner APIs, and their public APIs simultaneously, often for the first time. These three tiers have always existed. What’s new is the market pressure.
Internal API consumption is where the question gets ignored most often, and where it matters most. I wrote about this more than a decade ago when I was figuring out my own API stack — the first consumer of my APIs was me, and I needed to track that usage the same way I tracked any external consumer. Not to bill myself, but to understand the costs, identify unhealthy consumption patterns, and see the full picture of what was flowing through the system. Instagram and Tesla learned this the hard way; their internally-consumed APIs had no management layer, which meant attackers could walk through doors nobody was watching.
In the AI era, internal API consumption is exploding. Every agent, every automated workflow, every LLM-powered feature in your product is an API consumer. Many of these are consuming the same internal APIs that your engineering teams built to serve each other. The value exchange happening at this layer — between your AI infrastructure and your business capabilities — is now significant enough to warrant governance, cost accounting, and visibility. Not because you’re going to charge your own teams, but because you cannot manage what you cannot measure, and the costs are real.
Partner API consumption is where the value exchange framing does its most useful work. A financial relationship is often present here, but it is rarely the whole story. When I worked on the Recreation.gov RFP, the valuable thing about building a partner API layer wasn’t the per-transaction fees — it was enabling travel planning companies, outdoor recreation apps, and small regional businesses to build on top of federal recreation inventory in ways the government could never staff or fund directly. The value flowing back wasn’t money; it was reach, adoption, feedback, and services delivered to citizens that the government couldn’t deliver itself.
Partner APIs are how organizations extend their capabilities beyond what they can build alone. In the AI era, this is even more true. Your partners are now building AI agents that consume your APIs to automate workflows, extract insights, and create new customer experiences. The terms of that exchange — who gets what value, what obligations come with access, how abuse is prevented — need to be explicit. This is what service composition means in practice: understanding your API consumers well enough to design the tiers of access that make the exchange fair and sustainable for everyone in it.
Public API consumption is where the public lands analogy remains the most useful in my opinion. The value of making an API public is almost never primarily financial. It is about ecosystem, discoverability, innovation at the edges, and — in the government context — fulfilling a public mission that data belongs to the people who funded its collection. The question I was wrestling with in 2015 — are there any monetization opportunities around open data and APIs — was a real one, but it was the wrong frame. The question should have been: how do we make the value of this data visible enough to fund its continued maintenance and improvement?
Revenue can be part of the answer. Charging high-volume commercial consumers while keeping access free for researchers, nonprofits, and individual developers is a reasonable model, and one that several government API programs have moved toward. But the goal isn’t to monetize the data. The goal is to sustain the exchange — to keep the data good, keep access open, and grow the ecosystem of things that get built on top of it. That is what public API value exchange means.
I have been at this long enough to know that the hard part is never the framing. Calling it “API value exchange” instead of “API monetization” is only useful if it opens conversations that the other word closed. In government, where I have done some of this work, it does. In enterprise settings, where internal teams are being asked to justify API spending to leadership who didn’t prioritize APIs until AI forced the question, it also helps. In the public data world, where agencies are trying to figure out how to sustain open data programs that are politically popular but chronically underfunded, the value exchange frame gives you something concrete to point at.
The mechanics of this are service composition, rate limits, plan design, cost accounting, partner agreements — haven’t changed much since 2015. What has changed is the urgency, and the volume. AI has cranked up the consumption signal loud enough that the exchange is now impossible to ignore. I intend to spend more time on this framing going forward, connecting the decade-plus of thinking I’ve done on monetization to the reality of what is actually happening at the intersection of AI and APIs right now.
