Lately, API monetization has risen in popularity. APIs are the doorways to data and functionality, and these resources have a rising price tag. With the right product mindset, web APIs can deliver powerful new revenue streams. But setting up an API pricing strategy is a moving target that relies heavily on the domain and business model at your core.

The API economy has been hailed as “the next big thing.” And popular user-facing sites like Twitter and Reddit are now seeking to monetize their APIs (to some dismay). Clearly, there is rising interest in API-first business models. But how exactly do we set up direct monetization?

In our recent LiveCast on API Monetization, we brought in experts to share their on-the-ground experiences monetizing APIs with usage-based pricing models. One common thread for successful API sales is self-service — regardless of whether you adopt a top-down or bottom-up sales approach, the API platform must be self-serviceable to encourage easy signup and quick testing. Below, I’ll highlight these and other key takeaways from the event and consider tips to help you effectively monetize your API.

There’s Gold In Them APIs

Many reports indicate increasing interest in monetizing APIs. For example, 42.6% of organizations are now monetizing APIs, found Rapid’s 2022 State of APIs Report. Impressively, APIs and API-related implementations generated 41% of revenue for organizations in the US, found the MuleSoft and Deloitte Digital 2023 Connectivity Benchmark Report. These forces are anticipated to climb in the next decade, as the API economy will be valued at a stunning $72.6 billion by 2033, projects Future Market Insights.

The API economy is not just smoke and mirrors, either. More and more developers have come to rely upon APIs as the bedrock of their applications. As a result, Over 90% of developers use some sort of API, found Slashdata’s 19th Developer Economics Survey. There are also over 60 API-first companies that have raised $50 million or more, according to the API-First Index.

Understanding API Pricing Methods

Lately, it’s felt like a gold rush to monetize some of these services. But, refining an API monetization strategy can take time and effort. You must decide between a tiered model, pay-as-you-go pricing, or a combination of both. You may choose to feature-gate specific endpoints, or price calls differently based on their unique processing requirements.

“There are more business model concerns than the engineering requirements itself,” said Derric Gilling, Co-Founder and CEO, Moesif. “Each API business is quite different.” There are numerous factors to consider, and determining how to price calls is just the first step. As Gilling describes, billing options vary wildly. They could be constructed around transaction volume, revenue share, or data volume, or they may be more usage-centric or resource-centric.

API billing strategies generally fall into two main categories — prepaid and postpaid. A prepaid model is when you purchase credits ahead of time. Prepaid can introduce predictability into the payment process but can cause friction for some to get started. The other option, postpaid, is when you track usage and invoice later on.

Next, you must build out your packaging strategy, explains Gilling. API products typically adopt a tiered freemium model, usually with a good, better, and best plan. Enforcing a minimum spend, explains Gilling, makes things more manageable for customers.

You must also decide on how to invoice consumers. Either you adopt a recurring model, invoicing at the end of every month, or you use a threshold model, where you only invoice after a certain threshold is met. The latter might make more sense for APIs without much usage in certain periods.

The Importance of Self-Service

Developers have much more authority to acquire tools than in the past. As such, API providers need to demonstrate value very quickly — this is why it’s so critical to maintain quality developer experience and track measurements like Time to First Time to Call (TTFC). But in addition to appealing to engineers, API providers might be facing other internal blockers from departments like finance, procurement, legal, and security teams.

These factors make the self-service model for APIs very important, says Gilling. A self-service platform can sidestep these pain points with a clickthrough setup and fast integration. He recommends landing developers first with bottom-up self-service and then adopting the land and expand model where sales engineers become more involved. His “API flywheel” is a 5-step go-to-market strategy process:

1. Prove value initially
2. Developers grow their usage
3. Sales engages
4. Identify new cases
5. Accelerated usage expansion

Investing in self-service capabilities, like transparent documentation, sandboxes, and sample code, can reduce support inquiries and get developers up and running quickly. Yet, Gilling identifies some potential pitfalls of the self-service model. Namely, you really need transparent communication around things like pricing changes and deprecations. “To over-communicate is much better than to under-communicate.”

Lastly, Gilling recommends measuring key performance indicators (KPIs), like adoption metrics, engagement metrics, and retention metrics, to ensure the platform is stable and growth is improving.

Case Study: Three Takeaways From Anvil’s API Pricing Journey

In our LiveCast, Mang-Git Ng gave us an intimate look at how his company Anvil, a developer platform for paperwork automation, has been evolving its API pricing model to better match its go-to-market strategy. As he described, the team realized that most of their revenue was assisted by sales engineers creating custom pricing packages, although their efforts were initially aimed at product-led growth.

“Make sure pricing matches your go-to-market motion you see working for your team,” said Ng. He shared a handful of other recommendations for API providers to consider when pricing their services.

1. Keep it Simple

At first, the Anvil team had complex models that sought to capture all possible value. These were grouped into “multiplayer” plans with bucked usage and “single-player” plans with metered usage and limited features. However, there were too many options, and neither plan really fit the demographic they were targeting. They ended up minimizing the number of plans and simplifying them to cater to their target demographic.

2. Be Consistent

Ng also highly encourages API pricing models to be as consistent as possible. This means standardizing your value metrics, which he describes as “the unit of consumption by which a customer derives value.” Anvil’s mistake early on, he explains, was that the onboarding process had too many caveats, and it was slow rolling to meet that initial “wow” moment. By eliminating confusion in the pricing strategy, you allow customers to experience features quickly and, in turn, enhance the developer experience associated with your API.

3. Be Generous

It’s good to realize where the API fits into a customer’s requirements, and to provide them enough leeway to explore the platform, said Ng. For example, the Anvil platform offers a mix of no-code, embedded, and API integration capabilities. As such, he stresses being generous — always provide a free tier that enables API consumers to see the total value. “Our goal is to allow everyone to use every feature in development mode and to only charge in production.”

Monetizing Self-Service API Products

Although some commentators feel that enterprise buyers are souring on bottoms-up tech sales, our panelists still view self-service bottom-up sales as integral to the API economy. That being said, incorporating traditional sales tactics can also be helpful to “land and expand.”

Sales engineers can help identify these self-service users and identify new features or other departments within the organization that could benefit from the API. And even in a completely top-down approach, you still want a friction-free self-service API to build faith and create strong developer allies.

Still, it may take work to discover your initial customer value, which requires qualitative and quantitative feedback to uncover, says Ng. API pricing is also complex, and API products will likely mix and match pricing models. For example, you’ll often see tiered plans with prepaid pricing and pay-as-you-go on top. Or, you may adopt a more cloud-native usage-based and postpaid model.

Lastly, it’s good to note that direct monetization isn’t for everyone — there are plenty of reasons to retain open API access or embrace indirect models. For example, platforms with user-generated content supported by volunteer contributors should carefully weigh if API monetization is correct for their scenario. Regardless, platforms should realize the repercussions of major changes to API pricing plans and allow third-party developers ample time to respond.