API-as-a-Product is a growing concept in the software development sphere. As such, it bears some further definition and clarification. So, just what is API-as-a-Product? What are some ways we can monetize this approach? And, where is this trend heading?

What is API-as-a-Product?

An API-as-a-Product is a type of Software-as-a-Service that monetizes niche functionality, typically served over HTTP. Tech companies with API products often adopt a freemium model and utilize strategies like rate limiting to enable subscription tiers.

An API may exist alongside a primary offering or as a product in its own right. For example, if a business is developed first as a physical product or a Business-to-Business (B2B) offering, the API may be a premium extension. For a growing number of new companies, the API-business logic is instead the core offering itself.

This relationship has resulted in a new paradigm of API thought and design – API-as-a-Product. This model implies an API is core to the business logic, driving most of the business value. For API-as-a-Products, the API is not just the delivery mode; it is the product itself.

API-as-a-Product is roughly synonymous with an API-driven Software-as-a-Service (SaaS) offering, wherein the API powers the SaaS itself and the business logic around it. API-as-a-Product is the natural evolution of the B2B landscape, but instead of creating bespoke offerings for specific instances, API-as-a-Product essentially says, “here’s what we can do — how you integrate is up to you.”

Some good examples of this type of product offering are as follows:

• Stripe: A payment processing and eCommerce platform, Stripe offers an API to facilitate online commerce interactions. This API is not a business storefront itself — there’s no “Stripe Store” where you can sell and buy goods like Amazon. Instead, Stripe enables this commerce through platform offerings designed to ease overhead.
• Twilio: Twilio is, at its core, a communications facilitation platform. Designed to allow agents and customers to communicate on a wide variety of platforms, Twilio is not in itself a chat platform but is instead a connection platform. This core product offers communication benefits to companies who do not want to create their own communication channels and methods but would like to integrate proven channels into their existing infrastructure.
• Mailchimp: Mailchimp is a marketing automation solution that offers a productized solution to unified marketing efforts across different channels. This is an excellent example of a product that “levels up” existing efforts while opening new avenues for creation — while marketing campaigns may exist in the entity utilizing Mailchimp, it nonetheless offers a significant enough improvement in these efforts that it’s best considered a distinct product.

API-as-a-Product Consumption and Monetization Models

API-as-a-Product can be monetized in various ways. We’ve discussed this before, but it bears repeating. Monetization is highly dependent on the specific type of API product offering in question — for example, technical API products might charge per integration or per a certain amount of data transfer, whereas commerce or payment APIs might charge as a portion of revenue or through subscription models. The type and model of monetization are variable, and as such, API developers have relatively free range to choose the best monetization model for their specific use case.

Freemium/Tiered Monetization

A prevalent model in the API space is the freemium or tiered monetization strategy. In this model, developers offer basic API functions for free with some sort of limitation. Limitations can include time-bounded free trials, a certain number of allowed calls (akin to rate limiting), or even a completely free option for non-enterprise users subsidized by enterprise clients.

Ultimately, this model is based on the concept of accelerated cost for accelerated usage. A certain amount of balance must be employed in this model to ensure that what is provided in the free offering does not reduce demand for the premium offering while ensuring that the free option is indeed worth interacting with.

Bulk Cost Model

This model goes by several names depending on how revenue is generated from the bulk cost process. Pay as you Go is a bulk cost model in which the number of API calls made has an associated cost that is then passed onto the requesting entity. This costing can be for individual calls (usually assigned a premium cost) or bulk calls (typically discounted related to the individual call cost). For example, a bulk cost monetization model might say “each call costs 99 cents” and “1000 calls cost 500 dollars.”

While this model allows the customer to control their costs in a highly granular fashion, it can also obscure the end cost if the customer is not paying enough attention or modeling their costs accurately. This can be mitigated partially through proper modeling techniques or estimates from the provider, as well as clarifications on how each call is monetized (for instance, if replays are part of the API, does this count as a new call, or a repeat of an already paid call?).

Subscription Models

A subscription model is a cost-capped version of the Pay as you Go model and typically has a time period in which the subscription is active (for example, subscriptions may be weekly, monthly, or yearly). These models often have a top-level tier for utilization (e.g., 100 dollars per week and up to 1,000 calls) and typically also offer discounted costs for any overage outside the subscription level.

Unit Costing

This model utilizes discretely defined units to charge utilization. An API provider might charge per unit of use for infrastructure (e.g., number of GB utilized, number of discrete processor cycles employed, etc. — common with solutions like AWS), but can also charge per “unit” of process (typically called an “instance”), e.g., “5 Docker instances” or “3 users of the API”.

There is a version of this unit costing model called the “per seat” model in which each user has a set maximum number of calls they can employ and a time-limited period of access — in essence, you are buying a seat at the table for the solution.

Revenue Sharing

In this model, API providers claim a portion of the revenue generated from the API’s use. In a product sense, this is akin to something like Google’s advertising systems, in which a site can integrate advertisements can claim a certain percentage of the revenue, but not the revenue in whole.

For something like a commerce app, this may come as a premium charge on top of the item’s base cost or product. Integrating an eCommerce solution may mean that each product sold for 10 dollars results in 10 cents in revenue being shared with the API company, which, at scale, can add up significantly, even if there’s no “direct cost” to the company implementing the API. This can actually be a significantly better implementation for many companies, as the cost paid is part of the revenue generated, which mainly eliminates “idle cost,” where you are paying for a subscription that does not generate any value.

The Future of API-as-a-Product

As the web has moved to the microservice paradigm, thoughts around API development have similarly moved away from creating a single, catch-all solution for all use cases to develop extensible frameworks that allow the creation of solutions. The idea is simple — why try and solve every use case when you can create a low-level toolset for the problem owner to make their own solution? The end result is usually more tailored to the desired outcome.

With this movement towards framework solutions, the idea of API-centric business has become ever more critical as a core business logic. APIs are created for mass consumption, and as such, the new paradigm thought pattern has shifted from “what problem does this solve” toward “what problems can this framework enable solutions for.”

Of course, this movement has resulted in increased expectations for API products. APIs can no longer just provide a simple function — they require excellent developer experience, security, and reliability. For a real-world metaphor, the top car manufacturers in the world don’t simply make cars that go from A to B — they make cars that do so while offering top-of-the-line features and qualities that make them more attractive. The same is true of APIs as products.

What do you think about this movement to API-as-a-Product? Let us know in the comments below!