You’ve spent countless hours working on your new API. You followed all the standards and best practices. You executed an API-first strategy. You listened to your app’s users and to developers. You were careful to include the features they needed. One thing you have not yet figured out though is how you will make money with your API!

Does this sound like you? Are you comparing and contrasting different API business models to determine the best way to monetize your API? Do you have questions on how you should measure API activity? What kind of activity should you measure? How will it affect the monetization? Read on to find answers to these and other related questions!

Which Business Model?

First things first: you need to figure out what you should charge for and who should pay for API usage. There are plenty of API business models to choose from. John Musser did an amazing job covering 20 models in a single presentation, and I recently discussed 5 ways of increasing your revenue by executing your business model with an API. From all of these options, I will delve into three in this post; these particular ones offer you the best chance of monetizing your API. They are:

1. Inclusion: Provide API usage with all of your app’s payment plans
2. Independence: Having developers pay separately for API usage
3. Incorporation: Considering API access as a feature and incorporate it into certain plans

Free API Usage with Revenue Based on Existing Features or Plans

With this model, accessing the API is completely free. The goal of this approach is to make end users consume more resources from your app which are tied to specific plans. By consuming more resources, users are moved to a higher plan or, if you offer a free plan, to a paid one.

This is probably the easiest model to implement because you don’t have to write any code or do anything specific to make it happen. By offering API access for free, you’re encouraging developers to build apps and integrations on top of your API. By not tying API access or usage to a particular plan, you’re treating your API as just another way of consuming your application’s features. A good example is Dropbox which lets you use their API for free. In doing so, the cloud service encourages users to consume more storage and eventually end up subscribing to a paid plan.

The result of this model is that users will probably use your application more and in more sophisticated ways. They will have different ways of interacting with your app’s features whenever using any third-party app or integration. By doing this, they will be more engaged with your app and eventually they will have to move into a paid plan that supports their usage pattern.

Charge Developers for API Access

Another monetization method that you should consider is independently pricing your API. There are many ways to do this and pass on a bill to developers. I recommend implementing a “Pay as You Go” approach instead of offering plans based on limits. With this strategy, developers will pay only for what they use, and your revenue will be more related to your costs. This requires some sense of trust between you and the developer because there is no upfront payment. In the end though, your customers will better understand what they’re paying for. There’s a way to mitigate the danger that some customers will not pay at the end of the period after they’ve already consumed your resources. You can implement a hard usage limit that is triggered whenever a customer doesn’t pay for a given period. If their API usage reaches that limit, they won’t be able to make any more calls until they pay for all previous usage.

Charging developers will only make sense if you’re offering an API centric product; otherwise, developers will not find a compelling reason to pay just to connect with your API. A good example of a company following this model is Contentful; they are a company offering content management through an API. They provide different plans with some associated usage limits that they measure and charge for accordingly.

Charge End Users for API Access

Another way to monetize your API is to treat it like any other app feature that you can turn on or off for individual users. API usage itself is incorporated into your payment plans, and only certain users — those that are paying for a plan that includes the API — will be able to access it. This is probably the best way to measure the direct impact of your API on your monetization strategy. Salesforce is a good example of an app following this model. They don’t offer API access as an individual feature but they include it in some of their more expensive plans. Either way, end users will have to choose — and pay — to have access to your API.

How to Measure Usage

Now that you have some ideas on how to monetize your API, you’ll have to think about how to measure API usage. Without measuring it, how will you invoice for it? There are many usage patterns that you can monitor and measure, so I’ll focus on the most common metrics. These are the measures that will have a direct impact on your business and that your monetization should be based on. All the metrics should be measured for each customer or account, whichever makes more sense to your business.

Measuring the total number of API calls should be the first thing you do after releasing your API. By understanding how your API is being used by individual customers and globally, you’ll start to have a much better picture of its relevance for your business. Also, this metric is directly related with some of the monetization models presented before. The “Pay as You Go” approach, for example, directly uses total API calls to calculate how much a developer will pay.

Going deeper, you can start measuring specific API activity that correlates with some of your app features. Contentful, for instance, measures the number of created entries because they offer a content management solution. Amazon S3 measures the storage and data transfer because that’s what they’re selling. The goal here is to obtain metrics that are related with your cost structure and that should also be part of your revenue stream.

There are many ways to implement API usage monitoring. As LEGO and Västtrafik have done, you can start simple and increase the level of sophistication of your monitoring as adoption increases. Remember though that this will be a central piece of your monetization strategy. If measuring fails, you won’t be able to understand how your API is being used, and you won’t be able to charge customers.

Tools that Can Help

You can obviously implement the metrics measurement yourself. This may be OK as you’re incubating or scaling up your API. A better long-term approach, however, is to use a ready-made product due to the criticality of this system to your monetization abilities. An example of a solution that will help you centralize all your API usage is logstash. You can use it with a large number of programming languages and technologies to monitor log files for usage numbers. If you’d rather not manage the measurement solution yourself, you can use cloud-based solutions that will aggregate your logs and let you obtain insights. An example of such a service is Splunk. It receives data you send its way. You can then query it and generate calculated values, such as API usage. Depending on your specific needs Mixpanel and Segment might also be good alternatives. Mixpanel captures your metrics and lets you analyze them in a way that makes sense from a business point of view. Segment’s strongest point is that it lets you publish tracking data to over 100 different analytics services.

You can further abstract performance measuring and monetization by using any of the available API management platforms. Usually, these services offer a complete solution that lets you manage how your API is being used and how you monetize it. 3Scale, for instance, lets you easily define pricing rules and even manage all the invoicing and payment processing. Mashape offers this sort of functionality as well; they also expose your API to potential developers by including it on their marketplace and promoting it through social media campaigns. Layer 7 is another API management solution you should look into; they include a useful developer portal and the ability to assign various apps to different service levels with ease.

Conclusion

If you didn’t have a plan before reading this post for how you can transform all of your API calls into revenue, hopefully you now do. The two most important things are the business model and how you’ll measure API usage. You can make your API free to use and capitalize on the increased app usage. You can also charge developers or end users for API access. You may include the API in more expensive plans, and use it as a sweetener to get customers to go for that more costly plan. Choose the model that you believe will best resonates with your cost structure and your end users. To get there, make sure you measure everything you can related to how your API is being consumed. To do that, you should deploy an off-the-shelf API management service.

So, how are you going to monetize your API? Please share your thoughts here in a comment, on Twitter, or on our Facebook page. The community is listening!

[Editor’s note: Nordic APIs is an independent publication and has not been authorized, sponsored, or otherwise approved by any company mentioned in this blog post with the exception of Layer 7 and 3Scale. Layer 7, a CA company, and 3Scale are sponsors of the upcoming Platform Summit.]