One of the first questions an API team has to wrestle with is how to self-sustain the service. While there are typically various free options for hobbyists, APIs at scale must sustain themselves and generate a financial return if viewed as products.

Revenue generation is a significant component of any business in the API space and entails various potential applications. These models can be boiled down to two general types — direct and indirect.

Below we’ll discuss one of those types — direct monetization. We’ll look at five different ways to monetize APIs and consider how these models are different in practice. We’ll also look at some example API products for revenue ideas and identify whether these practices are as user friendly as they are effective.

Direct vs. Indirect Monetization

Before discussing specific monetization methods, let’s consider the fundamental differences between API business model categories. While we will focus on direct monetization in this piece, indirect models can be equally as valuable.

Conceptually, the difference comes down to the form of value generated. Direct monetization is easy to classify — direct payments, typically either in credit or cash, is the format one would expect. Indirect monetization is quite a bit different. It delivers value in non-directly-convertible cash analogs, such as brand valuation, marketing value, easier partner programs, operational streamlining, and so forth.

Direct monetization, however, results in a cash analog. Even if there’s no actual money handed from one person to another, the value is directly convertible, with credit, balance transfer, or in-lieu-of-cash payments being relatively common. This piece will specifically cover direct monetization schemes.

5 Methods of Direct API Monetization

1. Direct Billing

Direct billing is — as you would guess — the most direct monetization method on this list. Direct billing monetizes the API calls themselves, turning the API into a sellable, meterable product. This pay-per-call model can be lucrative, but it comes with the downside that it is somewhat restrictive for new users.

Without a freemium option, direct billing makes it hard for an API product to capture early success. Products need a critical mass of users before they are “successful,” and this critical mass is often the source of new growth. However, APIs are unique in that adopting any third-party API is a risk for the developer consumer. Integrations require a necessary amount of trust, which can only be built through production use.

Direct billing is perhaps the most impactful of these models. It’s highly lucrative, but without a low barrier for new users, pay-per-call can stifle early adoption. For this reason, product managers should simultaneously employ other methods of direct API revenue generation.

2. Freemium Model

One way to resolve the downsides of direct billing is by adopting a freemium model. This model, which has been popular in the software world for years, is less concerned about the total conversion of user-to-value. Instead, it targets specific paid users to have those paid users subsidize the free users.

In a freemium scheme, free users are allowed access to “lite” versions of core functionality. Many freemium APIs grant open access yet include heavy rate liming and time delays. Complex functions and the lifting of restrictions, however, are reserved for paid customers.

Freemium models allow API products to build a critical mass more effectively without losing potential users. Adopters are more willing to entertain the risk of utilizing a new API if that foray has zero cost outside of their own time. The hope is they will eventually convert to a higher paid tier.

The downside with freemium models is that they must carefully balance free service provision with revenue generation. For example, offering one free endpoint from a 100-function catalog is probably not the right balance for an average consumer. Thus, striking the right balance between giving services away to entice new users and giving away everything point-blank must be carefully implemented by the API implementer.

3. Enterprise Pricing

Eventually, API products seek not to monetize single users, but rather to monetize entire organizations. This B2B scheme is often referred to by another name — enterprise pricing.

Enterprise accounts may utilize calls that are heavily demanding of the API and require excessive resources. Such partner scenarios are necessarily more expensive than users who may only issue a single call each use period. In such a dichotomy, the most equitable and profitable mode of monetization is to shift that expense to the enterprise user to subsidize the free users.

API products often include enterprise plans within tiered pricing models (Freemium, Basic, Premium, Enterprise, etc.). When it comes to user experience and monetization, tiered plans can offer the best of both worlds. Businesses have more tolerance for pricing models as they are accustomed to paying for partner IT services. And, you avoid the direct billing aversion concern with average users.

4. Ad Revenue Sharing

While the previous methods monetize the API consumer, ad revenue sharing monetizes end-user attention. Ad revenue sharing is a great monetization approach, as it monetizes use by leveraging marketing efforts to market to a broader userbase.

In this system, API providers utilize advertising networks to generate revenue. This can take a couple of forms. One of the most common is embedded ads on consumption portals, allowing developers to retain a percentage of the ad revenue.

Ad revenue sharing is fundamentally free for the API consumer. For this reason, ad revenue sharing is preferred by some developers over a freemium model, as user attention can be rationed more easily than cash. Of course, ad revenue sharing does not apply to all types of APIs. Such a model best fits eCommerce advertising, affiliate networks, or product-heavy sales channels.

5. Upsell

Within an upsell model, API use is positioned as a bonus when selling a more comprehensive platform. In this scenario, the integration typically supplements a core experience. A SaaS application may offer a basic account that grants access to a web interface — the core application. Yet, the account must upgrade to a premium tier to export data from the application with a REST API.

An upsell model differs from the idea of direct billing in that the upsell API itself is not a standalone product. Instead, the API, or perhaps a more advanced version of the API, is locked only for B2B utilization. It’s part of a package. For example, a data aggregator for mobile application statistics may enable access to basic data for free and provide integration abilities at added costs.

While this seems like a freemium model by another name, the distinction is that, in freemium models, the “upsell” opens access to additional resources rather than avoiding artificial restrictions on the core API.

The danger of an API upsell is that it can often be misleading what, exactly, is allowed for a non-premium user. Open API access is almost an expectation these days, especially for paid SaaS services. Realizing API integration is locked behind a labyrinthine system of upgrades may cause frustration for developers. If adopting an upsell model, SaaS providers should do so carefully and transparently communicate these terms.

Monetizing API Products

The way you monetize an API can have just as much impact on developer onboarding as the service’s discovery, usability, and marketing initiatives. A poorly designed monetization strategy may generate significant income in the short-term, but limit a userbase before sustaining long-term growth.

On the inverse, the correct monetization approach can generate significant income while providing the financial backing to grow the underlying services and expand core offerings.

How an API provider chooses to monetize is dependent on a variety of factors, including the total cost of running an API product. Each provider should consider the above revenue options as helpful tools to craft the perfect implementation.

Have we missed something? Are there other direct API monetization methods? Leave us a comment below!

Kristopher Sandoval

Kristopher is a web developer and author who writes on security and business. He has been writing articles for Nordic APIs since 2015.