I was recently asked how I'd go about monetizing an API. It's my bread and butter. But I fumbled the question. What follows is my best thinking on the topic.

Skip to the good bits:

Monetizing your API is like turning a hobby into a side hustle or, to use a different metaphor, fixing up the junky car in your garage so you can put it to profitable use. A lot of companies have APIs that are already pretty useful that they let clients and partners use for free. This is like letting anyone at all stay in your guest bedroom and never charging rent.

An unmonetized API is a huge missed opportunity.

Monetizing your API:

Helps you cover the costs of maintaining and improving your API.
Can also bring in some extra revenue.
Can become become very profitable because an API typically requires far less effort than you would guess from the value it creates.
Tells the world that what you're offering is valuable.

So, whether it's funding your passion project or growing your business, monetizing your API is a win-win.

An API (Application Programming Interface) is essentially programmatic access to software's data and functionality. When you monetize an API, that's what your monetizing.

Let's look at high-level steps to monetizing an API and dig into each step just a bit.

Make Your API Valuable

The API needs to provide access to data or functionality that is valuable to someone or else nobody will pay for it. Just as with any other product, there's a balancing act between making the API a little valuable to lots of customers or very valuable to some smaller amount. You can tailor the API so tightly that it is essentially bespoke, but you're gonna wanna charge for all that one-off work and it's a real question whether the price you need will be within the budget of your specific client.

To find the middle ground where you product a product that is maximally valuable to the maximum market, it's important to conduct market research just as you would with any other product.

As appropriate:

Conduct a competitor analysis.
Speak with or survey clients, prospects, and partners or potential partners.
Survey client-facing stakeholders.
Analyze online communities in your target industries.
Keyword research.
Create a minimum viable product (MVP) as a test.

Make Your API Easy

Product managers often use a metric called time-to-value (TTV). This metric is a proxy for a number of important metrics: self-serviceability, simplicity or intuitiveness of design, likelihood that customers will need to engage tech support, and more.

Technical products have an analogous metric: time-to-hello-world (TTHW). Hello World is a reference to the most common simple program that a learner writes when starting to learn a new programming language or other technology. It's a simple program that just says, "Hello, World," or some such. TTHW is a measure of how long it takes a programmer to get up and running with a new language, database, API, or the like.

Developer experience (DX) is the broad name for all the qualities, products, features, and services that make TTHW short and onboarding easy. Improving developer experience, for a technical product, is the key way to reduce friction around adoption.

Key components of a good developer experience for an API include:

A consistent, intuitive API design that aligns with the UI is unspeakably important. Developers often anticipate the API based on the UI and want to intuit one part of the API by analogy with other parts. This is like writing a user guide in a standard format or making a consisten UI. Essential for adoption.
Clear, correct, complete, and concise documentation that explains: the overall structure of the API, where to find relevant product-related information, and especially authentication. Authentication is almost always explained badly and becomes very frustrating because it stops all other work to adopt the API. This is also a valuable marketing tools because it shows potential buyers how easy it is to use the API.
API reference material in a standard format.
Developer-friendly error messages so that a dev doesn't have to guess what they've done wrong when they go astray.
Software Development Kits are tools that manage an API in a given programming language and often handle lots of the nitty gritty details or simplify workflows. There are often SDKs avaialble for different languages but also different technologies like mobile or IoT.
Interactive toolboxes or sandboxes give developers a safe environment to explore the API without doing tedious bits like authentication. These are also valuable marketing tools because they let the developer "try it out."
Good versioning. This allows the software company to continually update the API while allowing its developer-users to lag a little and adopt at their own pace a bit.
Developer community or forums are handy for collecting feedback from developer-users rather than only their business teams. As the community develops, the community members also solve many problems for each other, reducing support costs.

Make Your API Secure

The API needs to be secure so that your clients will trust it and that it will generate revenue rather than liability.

Key ingredients to a secure API include:

Use HTTPS (SSL/TLS) only. Reject any requests that are routed via HTTP.
Strong authentication, e.g., OAuth 2.0.
Role-based access control so that clients get data on a need-to basis.
Rate limiting. Not only can you sell higher rate limits to trusted actors, but also, good rate limits prevent DDoS attacks. Rate limits must be clearly communicated in documentation for developers.
Input validation. Validate data to ensure that it doesn't have, for example, SQL commands that could be injected into your database.
Output encoding. This includes a range of possible outputs. For instance, database record numbers shouldn't be revealed because it's nobody else's business how records are organized in your database. Giving out that information would be like giving away floorplans to your house. Instead, ID numbers should be hashed into unpredictable public-facing IDs.
Error handling. Error handling should reveal sensitive information. For instance, providing stack traces could reveal vulnerabilities to hackers.

Determine What You'll Sell

Here's the good part. There's a lot you can sell when looking at your API. Commonly sold elements of an API and developer experience include:

Use of the API itself. Typically a price per use (request, in API lingo). A typical price might be $0.01 for 100 uses.
Increased rate of use. APIs typically restrict use to say, 70 or 150 or 1000 requests per minute. You can charge users for elevated limits.
Developer-customer support. This adapts a standard pay-for-service model to the realm of supporting developers. Consider charging a higher rate than you would for base customer service because the support is more challenging, requires a more skilled support staff, and adds more value for the developer-user. Likewise, you can charge for access to a developer community or to an ecosystem or marketplace of tools.
Usage analytics can help users optimize their applications and reduce their costs. This service is valuable and should be priced based on expected savings.

Determine Pricing

Pricing is always tricky but the goal is usually the same: maximize total revenue. It's no different for an API.

A key approach is flexibility and a willingness to make changes, walk back changes, and engage with customers. A key characteristic need for determining pricing is resilient. No matter what you charge, someone is going to be unhappy.

If you have a significant number of clients, partners, or even just fans using the API for free or very low cost already, the best approach is probably incremental and with broad exemptions. These increments can be increased and exemptions trimmed as time goes on.

An example of this approach would be to roll out pricing as follows:

Existing users of the API will continue to receive X requests per minute for free, up to a total of Y requests per month. X will be some number at about the top quartile of requests per user so that 3/4 of users will be unaffected.
New users of the API will get a lower rate limit for free and a lower total requests per month.
When you exceed Z requests per month, we will classify you as a commercial user and then: (A) you will pay on this pay-scale with the price per request based on total usage or (B) you can tell us more about your business and we can negotiate a bulk rate with support and other tools to keep you online.

Prioritizing for Profitability

Prioritizing, the first step in roadmapping, is the fun part. Once you've done the legwork of understanding where your business and API are, in terms of the above, you will be in a good position to understand what to do and when.

I generally recommend prioritizing building based on level of impact versus level of effort or ease of effort.

In this section, we're going to look at the general principles of prioritizing so that you can apply them to your API or other product scenario.

I measure level of impact in terms of revenue gained or retained and in terms of costs incurred versus costs saved. I try to do this in terms of dollars and cents as close as possible, though I admit up front that usually, the best one can do is something pretty fuzzy. If you do your estimating though, you'll at least have a rational, defensible decision rather than gut impulses and intuitions.

At a high level, you "divide" revenue or cost improvements by the level of effort for any particular bit of work. You get a ratio then and can identify, at least approximately, the possible developments that will have a large positive impact at low cost. These are the easy wins that should make your heart sing and that you should prioritize.

Estimating Revenue

A new feature is usually released to gain new customers or to keep existing customers satisfied and paying. Estimating new revenue or revenue savings can be really hard. And it's almost necessarily fuzzy except in the case of key accounts that have made a credible commitment to either buy or churn based on the development. In other cases, you want to use a little fuzzy math that goes approximately like this:

Σ ARR_logo x chance_of_leaving_logo

That is, for each likely affected logo, multiply their likely ARR by their approximate chance of walking or churning. Add those values together and you have a very fuzzy approximation of the likely value of a feature development intended for particular clients.

You can adapt this estimation strategy for features intended to attract or retain a larger set of less well-known clients or prospects.

Estimating Cost Savings

Internal tools, on the other hand, are typically about reducing internal costs by building efficiencies. Cost savings is, effectively, the same as revenue for some purposes because either way, you help the profitability of your organization.

You can use a similar strategy to do back-of-the-envelope math to understand approximate cost savings. Instead of thinking about logos earned or retained, though, you want to thing about things like:

teammates' time savings because time is money
expenses avoided for external goods or services like cloud hosting

We'll collectively refer to such things as "resources" even though there are significant differences between humans and web hosting services.

Σ Cost_before_adoption_resource - Cost_after_adoption_resource

That is, for each likely affected resource, look at its cost before and after, and then sum up those values.

As an example, take a simple bug fix. The bug has no negative affects on users but alarms them and causes them to contact customer support. Because the B2B2C business has ~3m monthly active end users (MAU), this bug reliable causes ~30k users per month to message tech support. Tech support has already created a quick response so that responding only takes 1 minute. Still:

Each TS response = 1 min
At $70k/yr per TS team member, 1 min cost = ~$0.58
With ~30k unnecessary 1 min messages/mo, the cost = $17.5k/mo

This little problem costs the company ~$17,500 per month. That's $210,000 per year. Let that sink in.

(Fun fact: the above case is from my own experience, real in its essentials, and not uncommon.)

Estimating Level of Effort

Estimating level of effort is also pretty fuzzy, but maybe less than you think.

The first key ingredient for an estimation is that team members, but product management and engineering, should have a good sense of the architecture of the software and of the approximate amount of time various efforts have taken in the past.

Tracking actual time spent on various initiatives becomes very important.

Storypointing

I prefer the Scrum approach of storypointing as a way of estimating combined with brief retrospectives after work is completed to get a sense of whether the original storypoint estimate was accurate. Once a steady method of storypointing is implemented, teams can look over future work and guesstimate with a reasonable degree of accuracy (+/- 25%, say) how many storypoints it will be. I never include my engineers in averaging how many storypoints are completed per cycle because I want them thinking mainly about the complexity or difficulty of a project and be, essentially blind, to how that correlates to velocity. This reduces the subtle temptation on a developer's part to fit storypoints to a time estimate. Likewise, I don't contribute to the estimation so that I can't try to fit the storypoints to my time constraints.

Actual Duration Records

Another approach to estimating is to ask engineers or use software to carefully track the amount of time a dev spends on a particular problem. Then, as outlined above, you can develop a sense of how long analogous projects will take the same group of engineers.

Costing the Level of Every

Once you have a sense of the approximate time required for each engineer for a particular project, you multiply those time commitments by approximate salary and get a sense of development costs. This approach is pretty rough, but it should give you at least clarity to the order of magnitude, but actually probably a good deal more precise than that.

One major factor to helping these LoE cost estimates stay accurate is to keep project units small. That is, don't try to cost out product development for 12 months, anymore than you try to plan out a product for 12 months. Too much changes. Think in 1-to-3 month chunks. This is handy because as you get to the 1-to-3 month mark in development, it's usually a good idea to step back, take stock of progress, and consider pivots.

Prioritizing

Looking at our quadrants above, we start getting a better idea of how to prioritize development work. The ratio of impact-to-ease-of-effort is our guide. The math here is simple, if fuzzy. It's basically an ROI calculation.

The possible projects with the highest ratio are the biggest, easiest wins. All things being equal, you usually want to do those first.

Take our example from above of the little bug causing low-grade pain throughout the tech support team and costing the company something on the order of ~$200k in sending messages to concerned users.

Even with domestic, highly skilled engineers, the bug - basically an incorrect call to action - did not take a year ($150k) of developer time. It didn't take a month ($12.5k) of developer time. It didn't take a week or a day. It took about one hour. Including testing time. That $75 investment saved the company, conservatively, let's say, $50k if not the full, estimated cost of $210k.

That's a 667x ROI. That's the full annual value of a number of that company's clients. You don't get to show that kind of ROI very often.

Go for it.

Low Value Work and Maintenance

It sucks, but sometimes that is work that must be down and has a low impact to effort ratio. Tech debt reduction is what usually springs to mind.

Here, the best policy is to set aside a certain percentage of developer effort to keep on these tasks as background, low-burner, as-you-have-free-time types of work. When there's not a ton of this work, you can have your engineers spend maybe 2-4 hrs per week on it (5-10%). When this work is starting to pile up, you can negotiate with stakeholders about other timelines so that you can give your engineers more time to work on this maintenance work, maybe even 40-50% of their time or even a dedicated sprint every so often.

This maintenance work is unattractive for product managers because it doesn't immediately generate profits, but if it's left unattended it will degrade your team's ability to innovate and eventually sink you.

Tech debt is like credit card debt. A little bit never killed anyone, but a lot of people have been ruined by failing to pay attention to it.

Collect Feedback and Data

As with any other product, you must solicit and collect feedback and data as often as possible.

Creating and monitoring a developer forum or community is a powerful way to get qualitative data and new ideas for improvements or development.

Your web service, the software that provides the API to users, can be a treasure trove of data. To leverage the service itself, it only needs to keep detailed logs of who accesses with API methods how and when and what the results were. The more granular data you gather, the better. With this data, you can objectively measure useful metrics about adoption, stress on the service at different times of day, and so on.

Iterate

With feedback and data in hand, you can iterate not only on making the API more useful and easier, but also on monetization strategies. You might increase the available free-of-charge usage in order to attract more developers, or you might increment the price slightly or conduct A/B testing on new pricing schemes.

Bear in mind that API adoption is usually slower than new UI feature adoption. There are several reasons for this:

APIs are mainly used by businesses and organizations whereas UI features are used by a much larger number of end users.
Organizations make decisions and plans more slowly than individuals.
New API features typically take more time for a developer to figure out than a UI feature takes for an end user to figure out.
APIs features are typically further upstream, value-wise, than UI features. A single API request might add value for thousands of users.

So take it easy on yourself if your API doesn't get 10m hits the first day you release it. To give an example, at one company where I worked, when we released a new endpoint that had a lot of pent-up demand, in the endpoint's first month we got something like ~1000 uses. That was at a company with ~350 enterprise clients and ~20m API requests monthly. So, that 1000-ish requests didn't look like a big win. But within 6 months were were at ~10k-20k requests per month across a couple dozen clients, many of whom were moving or had recently moved their integrations into production. That's not too shabby. From there, our numbers only went up.

Onward

Monetizing an API can be a game-changer for your business or project. It's not just about generating revenue; it's about creating value for your users and meeting their needs. By following best practices, offering a fantastic developer experience, and continuously improving your API, you can attract and retain users while building a sustainable income stream.

Remember, the key lies in striking the right balance between monetization and user satisfaction. Whether you choose a freemium model, subscription-based pricing, or pay-as-you-go, always prioritize transparency, fair pricing, and clear communication. Your API's success will ultimately hinge on how well you understand your audience and adapt to their evolving requirements.

Monetizing an API