3 Ways Your APIs Are Leaving Money On the Table

MuleSoft & Deloitte recently published their 2023 connectivity report, and the standout statistic for me was that based on over 1000 responses from mid to large companies around the world, APIs were responsible for generating 38% of an organization’s revenue.

Despite that statistic, I believe that for many companies, this number is far more aspirational than reality, but it has caused many companies we speak with to ask themselves, are our APIs leaving money on the table?

Recently, both Twitter and Reddit have faced the same question publicly and have clearly indicated that they believe their APIs represent untapped revenue streams, and many of the traditional enterprises we work with have come to the same conclusion.

Based on these recent experiences, we wanted to share some of the main ways we see companies leaving money on the table with their APIs.

Mistake #1: Not Adapting Your Existing API Business Model

Let’s first quickly explain two important API monetization types: Directly-monetized APIs are ‘pay to use’ (i.e., Plaid’s API catalog for financial services). Typically, in these cases, the API is the product, and thus, it makes the most sense for customers to pay to use it. Another common example of API products is Twilio & Stripe.

Indirectly monetized APIs are those that are free to use but amplify the consumption of a digital product or platform that creates revenue in another manner.

A great example of an indirectly-monetized API catalog comes from eBay. In eBay’s case, a core objective is to make it easier for power sellers to list and close more auctions, because eBay makes money every time that an auction closes. The more effective the API, the more revenue is created, but no one pays to use the eBay API, and charging for use of this API would be counterproductive as it would de-incentivize eBay’s largest clients to list auctions on eBay.

As an interesting related fact: as early as 2015, eBay reported that it derived more revenue from auctions listed via API than those that were not, so this has clearly been a very effective revenue-generating API strategy that does not involve directly charging for access to the API.

Although the distinction above between directly and indirectly-monetized APIs is fairly clear-cut, things get murky for enterprises when their indirectly-monetized APIs start being used in ways that were not originally envisioned.

Reddit’s recent situation is an excellent example of this shift. Traditionally, Reddit’s APIs were used by partners to integrate with its platform and ultimately make it easier to drive more users to the platform by making its content easier to consume in different ways. More eyeballs = more advertising revenue = a win for Reddit and an effective indirect API monetization model.

However, Reddit eventually learned that AI companies were using Reddit’s vast treasure trove of data to train their large language models (LLMs). This activity did nothing to benefit Reddit and, in fact, drove up their operational costs of operating their APIs at higher transaction volumes while having no effect on advertising revenue. As a result, Reddit announced that they would be placing limits on their API and begin developing a paid access program (i.e., they were going to directly monetize their previously free-to-use APIs)

Reddit’s situation represents what we believe will be an increasingly common opportunity for companies to monetize unique data assets that will be highly valuable as investment continues to flood into AI and the various chatbots vie for dominance. For data assets that exist publicly, like Reddit’s, putting API limits in place and developing methods to prevent site scraping are critical to allow you the flexibility to build a digital business model around your valuable data.

Similarly, if you have uniquely valuable data that exists only behind a firewall, developing APIs that allow it to be easily consumed by AI startups for LLM training could represent an entirely new revenue opportunity with several years of growth ahead.

Mistake #2: High-Friction API Onboarding Processes

Developers are in search of the most efficient solutions to their problems. If you are lucky enough to attract a developer to your portal through advertisement or organic search, one of the worst things you can do is force a developer to engage in a sales conversation before letting them try out your API to determine if it is indeed the solution they are looking for.

Despite this, many companies today allow access to their APIs only after a corporate partnership is signed, or only after a sales qualifying conversation occurs. I’m not sure about you, but I know exactly zero developers who would voluntarily choose this as their path to API adoption.

“But I’m in a highly-regulated industry,” or "but we are only targeting large enterprise partners" you might argue… and I would say in return that only rarely is this an excuse for requiring a sales process as described above. We work with companies in the healthcare and financial services industries, both highly-regulated, both whose traditional customers are other large enterprises. In all cases, they have found creative ways to allow self-service access to their APIs in a way that protects the company from fraud & abuse, complies with privacy regulations, and opens up new sales channels that did not exist prior (more on that here).

Mistake #3: Subscription-Only API Pricing Models

For companies already directly monetizing their APIs, one of the largest missed opportunities for increased revenue comes from the lack of usage-based pricing models. Although we are firm believers that monthly or annual subscription plans should be a part of most API pricing models, they should not be the only pricing model offered for access to your APIs. If your API storefront is properly designed, it should cost you next to nothing to onboard new potential customers, and therefore, the risks of a low-cost pay-per-use plan to your business should be very low.

Pay-per-use API plans allow developers to create small experiments with your API at a negligible cost before putting the idea into production and ramping up usage (at which point they will likely migrate to the fixed-cost subscription plan you wanted to force them into signing up for in the beginning).

However, if you do not offer a pay-per-use plan but instead force developers to sign up for a fixed subscription cost (even after a free trial, which is helpful but not a complete solution to this problem), you are creating a completely unnecessary barrier to sale and losing potential sales before they have a chance to experiment with your API and determine if it is a fit for their project.