Over the past decade or two, APIs have quietly shifted from behind-the-scenes infrastructure to fully-fledged products. And companies that treat them as such are making big bucks doing so.

According to Postman’s 2025 State of the API Report, 65% of organizations now generate revenue from their API programs. And, among organizations that make money from their APIs, nearly a quarter derive more than half their total revenue from their API programs.

WSO2’s Derric Gilling joined us at our 2025 Platform Summit to talk about building killer API programs that drive growth. “Monetization is a key piece to that,” he observes, “but there’s the whole go-to-market side of things as well.” Indeed, you can have a slick and intuitive pricing strategy in place, but you won’t make any money if no one is actually using the product…

Below, we’ll consider the changing landscape of API consumption, from purchasing habits to what consumers expect when investigating new products. We’ll also look at some actionable tips Gilling highlights for polishing an existing API program or building one from scratch. Together, these metrics and tips ultimately determine whether developer-led API growth is sustainable.

Buying (and Building) Habits Have Changed

Gilling mentions two major trends within the API ecosystem:

1. Buyer power has shifted towards individual developers and away from organizations.
2. The overall cost of software has dropped significantly compared with on-prem solutions.

Developers are often spoilt for choice when it comes to picking solutions, with only the most prohibitively priced enterprise options off the table. The final decision often lies with them, but as Gilling puts it, “getting developers to adopt your APIs is hard… They’re very opinionated, they have different frameworks they believe in, they don’t always like to talk to sales and marketing.”

And, he continues, “they like to code. They don’t want to set up a 30-minute sales call and try to figure out how to use your APIs through a Zoom meeting.” Although they have stakeholders to deal with, including security, budgeting, and procurement teams, many prefer to get their feet wet and try before they buy as part of the evaluation process.

This shift from long sales cycles to self-serve evaluation (more on that below) is reflected in modern developer relations and developer experience best practices. Where unicorns like Twilio and Stripe were once outliers to the status quo of UI-driven experiences, their approach is rapidly becoming the norm.

“The way software is being consumed is very different from just a couple of years ago,” Gilling says. “The prevalence of MCP and new protocols means that any user can effectively start to trigger API calls through an MCP server. That means organizations and software providers now need to be API-first as well.” By extension, they also need to be developer-first.

Removing Friction, Accelerating Adoption

In this context, developer-first can be considered as a rework of the product-led growth (PLG) model. However, Gilling highlights that where PLG models typically lean on a single customer persona (or a small set of them), APIs must cater to many developer archetypes with their own use cases, technical levels, and preferred frameworks.

Although an API can be showcased effectively through sales calls, screenshots, and YouTube videos, these aren’t how most developers prefer to evaluate them. Rather, Gilling suggests, “we need to reduce the number of obstacles to demonstrate initial value.”

That means providing clickwrap agreements (aka click-through terms of service agreements), self-service onboarding with clear documentation and instant API key availability, and accelerating the rate at which key checkpoints like time to first call and time to first hello world are reached.

“This allows you to bring a lot of developers onto your platform initially and enable them to pay a token amount,” says Gilling. (He’s talking here about soft paywalls with easy credit card options or freemium and sandbox options.) “You’re not trying to sell them an entire house,” he continues. “You’re just trying to provide them with a paint sample.”

From here, you can sell through existing developers by identifying new use cases, looking at ways in which you can expand their usage, and solving enterprise needs based on the different types of industry that are actively using the API.

Monetization and Metrics

There are various monetization models to consider when looking to generate revenue from APIs — something that Gilling has previously covered for us, including monetizing proprietary data through APIs — with their own advantages and disadvantages:

• Direct/subscription revenue
• Usage-based billing
• Platform/marketplace
• Partner ecosystem

The main thing, Gilling asserts, is that “we need to make sure that we’re aligning that business model to customer value.” A problem here is that many commonly tracked metrics, like transaction volume, don’t always map easily onto APIs. A thousand API calls might sound impressive, but perhaps it could all have been done with a single call to a different endpoint.

On the flipside, consider some of the KPIs tracked in the API space: SOA metrics, uptime, infrastructure metrics like CPU and memory, and so on. “Not a single one of these is really aligned to business value,” Gilling says. “These are things that are operational in nature.”

On that basis, he suggests that “if this is what you’re using to track the success of your API program, you’re going to fail.” For sustainable growth, we need to look elsewhere.

Measuring What Actually Matters

When thinking about relevant metrics, he argues, we can boil them down to three different product goals with priorities that vary over time:

1. Adoption goals
2. Engagement goals
3. Retention goals

For any new API program, adoption is initially the highest priority. As such, the focus should be on reducing time to sign up, reducing time to first hello world, reducing time to first app, and so on. As well as promoting the API, so people actually know that it exists.

On engagement, Gilling emphasises relevance. “It’s one thing for an API to say ‘here are 50 records for you’ and another to say ‘here are 50 records that match the results of the query the developer is looking for’.” Quantitative metrics like API calls or emails sent are all well and good, but fail to capture how useful the service is to an API consumer when considered in isolation.

Any attempts to improve engagement should ideally be reflected in retention. “We might have an initial drop off, but good product retention curves eventually flatten out. Sometimes they’ll smile up, and that’s usually a pretty good retention curve.” The real problems come when a retention curve drops to, or approaches, zero because it means (no matter how well things are going on the adoption side of things) we’re attempting to bail out a sinking ship.

Supporting at Scale Unlocks Exponential Growth

“If you do get a developer-first motion, you might end up with thousands or even millions of developers on board,” Gilling says. “And you’re not going to have enough sales or support people to make sure all their needs are handled.” Those issues might include things like:

• Onboarding issues
• Changing business needs
• Deprecation of APIs
• Unsupported languages, SDKs, or frameworks
• Billing issues

For this reason, he argues, an emphasis on self-service and mitigating potential issues in advance wherever possible is a vital ingredient for sustained long-term growth. And “it’s better,” Gilling suggests, “to overcommunicate rather than undercommunicate.”

In practice, that means notifying customers about quota and budget limits, deprecating gracefully by providing as much notice as possible, offering visibility and reports on their usage in real time (or as close to it as you can), outlining upcoming developments on the road map, and so on.

However, Gilling also sums it up well when he says that “supporting developers is hard.” They have their own specific use cases, which can vary significantly from consumer to consumer. As well as trying to make life as easy as possible for them, and keeping their projects running. As Gilling quips, “Don’t break their stuff!” As such, it’s well worth trying to gather feedback as you build.

Look at which endpoints your consumers are using, delve into what people are building with the API, and ask them what else they’d like to see from it — feedback forms are your friend — so you know what to do next to keep things trending in the right direction. If you can make your API easy to try, even easier to love, and hard to live without, then you’ll be off to a running start.