API Business Models

Monetize Your API

2kviews

Going after the developer channel with monetized APIs can be a lucrative opportunity for traditional enterprises. Furthermore, targeting public developers can provide many benefits beyond collecting revenue.

If you’ve got an API program running in your business, you may have thought about monetizing APIs, and there’s a good chance you have valuable data that can be sold through an API product to developers.

In my previous role at Telstra, Australia’s largest telecommunications company, I was the owner of TelstraDevtheir public developer program – where my team monetized APIs and built a growing community to attract developers to Telstra products. We were one of the first traditional companies in Australia to start monetizing APIs, from 2017. I’ll be referring to my experience throughout this article to provide real-life examples of where and how APIs can be monetized.

Monetizing APIs helped Telstra’s overall API program as it put in place a success metric for APIs that all executives in companies understand: revenue. No longer were APIs just about business efficiency, they were about getting access to new revenue streams from an audience that hadn’t been addressed before, that is, the developer community. So, having an API Program that is generating revenue can provide a real boon to the company and the program itself.

What does monetizing an API mean? 

There are several definitions people attribute to monetizing APIs. Essentially any API that drives revenue, directly or indirectly, are given the “monetized” moniker. Those APIs that indirectly drive revenue (for example: partners selling your services and using APIs to place orders, or an API that’s part of a product and the product wouldn’t sell without the API) are very important to monetizing products and increasing market share, however, in this article I will only cover the most obvious type of monetizing, and closest to the definition: charging for the use of a product through your API. This could be charging per API call or by subscription.

When do I monetize a public API? 

Typically with an API Program, monetizing APIs comes quite later in the maturity of an organization’s program, but it does always pay to have in the back of your mind (even in the early days) that some of your APIs may be monetized one day. This will give you a better “externalizable” perception throughout the program and will help ensure that APIs are built as true products (easy to use, re-usable, beautiful and all that). Lastly, thinking with an “externalizable” mindset will pay off down the track as you can more easily release previously made APIs to public developers, as they will already be very close to being constructed for public consumption. 

During the early phases of an API Program, you should be getting enough feedback from developers that will give you clues as to what public developers might pay for. It’s even better if some of your APIs are already used by external developers (perhaps as a value-add to an existing product) so that there is an outside community to consult and to gather feedback from, as this will better validate your monetizable API candidates. If given all that you get nothing, well hey, not everything can be sold, and understanding this will help make sure you’re not focussed on red herrings in your program. 

From my experience at Telstra we followed a pretty typical journey, although we did release public APIs at the start of our program, and these APIs were released with monetization in mind. Getting developer feedback and growing demand for the SMS API at Telstra provided more than enough validation that we should monetize. Further, the growing public developer community provided us other insights into products that we never thought about monetizing, such as Telstra’s Event Detection API, which helps prevent SIMswap fraud. 

How do I monetize an API?

On top of the usual productization processes in your enterprise, you need a way of advertising your plans, getting customers to sign-up to them, and have a way to rate, bill and invoice those plans. In Telstra we chose Google’s Apigee platform, as it has a specific monetization module built into it for the purpose of monetizing APIs. That said, it doesn’t cover all the bases and we still had to hook in billing engines, invoicing and some customization to various attributes and to sort out how the monetization engine worked. Overall though the functions of the monetization module provided great plug-and-play capabilities for monetizing APIs as it covered most of the core functions we needed, including: 

  • Packages and plans – the ability to set pricing on different plan models such as: per API call, by subscription, tiering models, post-paid and pre-paid plans, as well as plan lifecycle management. 
  • API product integration – linking the plans to specific API products to enable individual products, or sets of products, to be rated and priced in particular ways. 
  • Developer portal integration – allowing for self-serve purchasing, tracking of usage and billing reports to customers. 
  • Rating – the tracking of API usage against plans, applying rate-factors and applying charges to the usage according to the plan. 
  • Billing reports – to be used as inputs to billing engines to bill customers, and for customers to generate billing reports via the portal. 

Besides Apigee, there are other technologies out there that allow you to monetize your APIs and are worth exploring including IBM’s API Connect, Redhat’s 3scale, and even AWS Marketplace. The key is that no one technology will give you everything you need out of the box, and you’ll need to consider choosing a technology that best fits your business needs.

How do I price my API?

Of course, when monetizing APIs you’re going to have to come up with a price. Sometimes this can be relatively easy, where you may have a product already in market whose transaction mechanism fits neatly with an API-charging-model. For example, when we came up with a price for Telstra’s Messaging API, charging per SMS and MMS was a pricing standard already in-market.

Where pricing can become difficult is when you’re launching an API product that is exposing a unique service and market data is hard to come by. We had this challenge with the Telstra Event Detection API, which was a new service to market without market data and what price to put on the API: whether it should be per API call, or some kind of subscription fee, and what calls we should charge for. 

As a rule, not all API calls on an API are chargeable. You wouldn’t charge to get an OAuth token, or if the API comes back with a 400 or 500 error. Pricing can be an important consideration when building the API, to make sure that you can charge for particular call types, and in a lot of cases have different rates for calling different resources, or getting different responses from the API. All these things need to be carefully worked through as part of your product pricing strategy. 

To get developers started and enticed to your monetized API product, it’s a good idea if you can offer a free tier of the monetized API (with limitations on features, or a limited volume in a given period, or limited by a time window). This will allow developers to get started at zero cost with your API, and make sure that there is enough free stuff for them to develop a good outcome. Think of the free tier as a way to enable your developer customers to get a production outcome out the door so that they can start collecting revenue, which then helps them pay for your service. In the Telstra case, they offer 1,000 free SMS/MMS for every registered developer. 

For the type of plan you offer customers, it will be somewhat dependent on the product that sits behind the API. Remember that developers are not paying for the API, they are paying for the product that the API delivers (the API is just a delivery mechanism for the product). The product behind the API is the thing that has value, and that should help clarify what kind of plans you can offer; a subscription plan, price per request, price per response, prepaid, postpaid, etc. If at all possible, start a pay-as-you-go plan that is priced only on consumption, as this presents a very low barrier to developers where their costs will only increase with the use of the API. 

Lastly, keep in mind pricing is allergic to experimentation and fiddling with pricing can be dangerous as it’s guaranteed to annoy your customers (unless the price is coming down), The first price you publish sets a precedent in market (yes, not everything in the software world is agile, and pricing is something to get right the first time). 

What about marketing and sales?

This is where a different approach will need to be taken to your traditional company processes, to maximise the awareness and likelihood of sale of your API product. 

Selling APIs turns the traditional sales influencer model on its head, where traditionally the sale influencers in a business is from the top-down (i.e. targeting the CxO and senior management), where-as selling APIs is selling to developers, which is a bottom-up approach. This is important to understand as even if you’re successful in selling the product to the CIO, the people using and integrating that product will be the developers and you may find it doesn’t get used at all. 

Making sure the product is best fit for developers and enticing developers to use the product is the goal. Effectively you want to encourage shadow-IT of your API to developers within your customers business, then when the traditional sales team approaches the business you know you’ve already won the hearts and minds of the developers who will be using the product. 

On top of this having developer relations, or developer evangelists, as part of your API Program will significantly help in getting awareness for your API products out to the developer community. They will also run events for you that are targeted for this community such as meet-ups, hackathons and conferences. They will be the voice of the developer which will in turn help ensure great product positioning, and feedback on the product itself. 

Taking a product approach

Overall the monetization of APIs broadly follows the same road as bringing out traditional products to market, so taking a product-approach is key to successfully generating revenue from your APIs. It’s an exciting journey, that opens new customer channels, new revenue streams and product opportunities that weren’t possible before the world of APIs.

 

Photo by Melissa Walker Horn on Unsplash

David Freeman
David formally ran Telstra’s API strategy and was the owner of their public developer program. He is now running a company, Sonrai Consulting, dedicated to helping other businesses on their API Journey.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture