We’ve written a lot about API-as-a-product and API monetization over the past few months, but we’ve often left a key point unspoken in pieces like this: when an API is your product, you need to start treating it like one.

Sounds obvious enough, right? Unfortunately, the tendency to think of APIs as a side project or something “for the techies” can persist even after they’ve emerged as a fully-fledged product. Failing to keep on top of these can result in uneven growth or total stagnation.

Below, we’ll delve into some key metrics to consider when productizing an API and see how they can help improve a service’s performance and your bottom line.

“Must Track” API Metrics for Growth

Andrew Stiefel of F5 outlines a few different categories of API metrics and breaks them down into the following categories:

• Operational metrics (usually related to performance and reliability)
• Adoption metrics (referring to how, and how many, customers are using the product)
• Product metrics (how the product supports business objectives)

You’ll notice that the metrics listed below span all of those categories, which is a reflection of the holistic view best taken with API metrics: an API with high levels of churn or poor revenue, even one that offers lightning-fast service and perfect uptime, can’t be thought of as a good product.

The metrics suggested below should give a good snapshot of a typical API product, but they shouldn’t be considered exhaustive — there are literally hundreds of metrics relating to APIs that you could track.

1. Time To First Call (TTFC) / Time To First Hello World (TTFHW)

We’ve written before about the importance of Time To First Call (TTFC) as a metric for API usability. In that post, we reference Ably’s benchmark for a Time To Hello World, a comparable metric of less than 30 minutes to score 5/5 in their ratings.

TTFC values depend, to a certain extent, on the complexity of deploying an API. Sometimes there are steps, like approval for API keys, that you just can’t skip. However, you can always work to ensure that you’re doing everything to keep TTFC low.

A possible example to keep an eye on? The time it takes for a new API consumer to make a basic call, such as their first GET call to example.api/user to retrieve user data.

2. Time To First Value (TTFV)

More commonly referenced when talking about customer onboarding and engagement, Time To First Value (TTFV) retains its relevance here. In this case, “value” doesn’t refer to a numerical value but to the first time a customer finds the product useful. In other words, how long is it until a developer “gets it”?

The tricky part is figuring out how to measure TTFV in your onboarding process. Insightly provides a couple of examples of immediate time-to-value, like picture resizing or link shortening. While these may not be relevant for more complex products, even just considering TTFV, and setting a target for TTFV, can be a great first step.

In the case of APIs, you might consider TTFV to be the time it takes an API consumer to create a working integration within a functional, live application. It’s difficult to capture the “eureka!” moment, but this should be a pretty good estimate.

3. Churn Rate

Abandonment, inactivity, and account deletions are things that startup founders are borderline obsessed with. After all, it costs considerably more to acquire new users than it does to hold onto existing ones. To evoke an old expression: acquisition is vanity, retention is sanity. But you can’t please everyone, which is why you’ll never hit a churn rate of zero.

If you’re losing more consumers than you should be, GoCardless has a useful guide to churn rates which might explain why. There are many possible answers: insufficient documentation, cost, failure to deliver on marketing promises, and more.

4. Number of Active Monthly Users

Monthly usage and churn are sort of two sides of the same coin. And it’s absolutely worth monitoring the number of unique users your API has. Let’s say, for example, that you’ve chosen to implement (or are considering) a tiered pricing strategy for your API product.

You might see high usage rates and assume everything is going great, but that may not be the case if the bulk of that usage comes from a handful of power users. In that case, a model that charges per request, or per 1000 requests, could be more suitable.

Example: In 2021, Twilio recorded that they had more than 250,000 active users with a full-year revenue of $2.84 billion in the same year. That knowledge is vital for determining the cost of acquiring new users, their total lifetime value, and so on.

5. Revenue Growth

The goal of most products, with the possible exception of those designed to scale rapidly and secure investment, is to make money. In an ideal world, whether by serving additional customers or increasing usage rates, your API will be doing that more and more every month.

Stagnant revenue growth could be due to over-reliance on a handful of power users, a pricing strategy that fails to consider scaling costs, or various other things. Modeling different revenue models and closely tracking revenue growth are both important for ensuring that an API product is, and will continue to be, a profitable use of resources and development time.

6. Uptime

Uptime is a simple metric, no doubt, but one that’s often included in service level agreements (SLAs). 100% uptime will always be the goal, albeit one that not many of us are ever likely to reach.

However, even seemingly minor improvements to uptime can have a huge impact: the annual difference between 99.9% uptime and 99.999% uptime is the difference between eight hours (an entire workday) and a little over five minutes.

7. Error Rates

Knowing the frequency of errors returned could signify problems with your production API or how it’s described. But simply measuring the number of errors your API is experiencing isn’t actually all that useful on its own — API developers really need to be measuring the types of errors that an API is returning.

For example, a deluge of error messages related to missing fields could indicate that your documentation is incorrect. Armed with this knowledge, you can jump in and fix any errors. And this all starts with API design. For example, using the proper status codes from the get-go will make it much easier to track these metrics later. Depending on the status code, you may be able to identify errors with different causes, from sloppy code and poor documentation to attempted security breaches.

8. Requests Per Minute* (Total and Per-Client)

It’s good to know how often your API actually receives requests. But more important is finding fluctuations or usage peaks that could impact your service, such as unexpected outages or costs. Monitoring the rate of requests can help detect brute force attacks or other suspicious activity that could lead to data breaches.

On a more granular scale, you might consider monitoring the number of requests you’re receiving on a per-client basis. That information is necessary to invoke rate limiting, and could help you figure out if you have heavy users who could benefit from a custom Enterprise plan.

*We’ve mentioned “minute” here, but you could substitute that for hour, day, week, or month.

Future Proofing With API Metrics

It’s difficult to overstate the importance of tracking API metrics because, provided you actually act on them, they can be really valuable for improving your API products.

It bears pointing out, however, that metrics like these are worth tracking regardless of whether you’re not your API is productized or monetized. If any of the above aspects of an API aren’t up to scratch, it doesn’t reflect well on your organization as a whole.

The good news is that many API management platforms provide access to analytics as a standard. If you want to go a little deeper and really push to optimize availability and performance, we have a breakdown of 20+ API monitoring tools to plug into your workflow.

We’ve seen above how API metrics tend to fall into broad categories like operational, adoption, and product, so accountability is critical here. Figuring out what metrics you will track and who’s responsible for improving each should be a company-wide effort so no metric gets left behind.

Then, if/when you embrace the idea of API-as-a-Product, the whole process will be a lot easier. Until you’re monitoring statistics typically associated with products designed to make money, it might be difficult for your team (and external stakeholders) to think of an API as anything more than a useful little side project.