Invoice that API, Please
First lets start off by clarifying not all APIs requires you to charge for their usage to bring value to your company. There are many different business models for APIs beyond the developer pays. In fact, the developer pays makes up a very small percentage of the APIs in the market today. For the remainder of this blog I am going to focus on that small percentage – the developer pays.
Monetizing Your APIs
Billing is a complex subject when it comes to any product. APIs are no different; you need to price, invoice, and collect payment.
The most difficult task is coming up with a pricing model for your APIs. Lets clarify a bit here too, when we say we are pricing the API, it really isn’t the API, it is the service that the API is exposing. What is the value of the service that the API is providing an interface to? Because you are charging for it, it must be of fairly great value to the developer or partner who is going to leverage the API, and it must be of value to the End User who is going to use the app or service that the developer or partner built.
There are several different pricing models around APIs. Below are a few of the basic ones.
- Subscription - You pay a yearly/monthly/weekly fee and you are allowed fro example; x number of calls, x volume of data, or some other measurable metric by which you can limit. You can have tiered options, freemium options and overage charges as well. Think of your cell phone bill as an example.
- Transaction Fee - You pay a transaction fee for the service usage. For example a % of a credit card transaction if you are a merchant payment API.
- Pay As You Go - You only pay what you use. For example, if you are a messaging API you may charge so many cents per message sent or received.
- Unit / Token / Points - You buy x number of tokens and each API call uses a certain number of tokens. For example, maybe a create API call costs 3 tokens and a get costs only 1. As a consumer you buy 100,000 tokens to spend per month however you would like. The benefit of this model to the consumer and provider, is if a provider brings on a new service no new contracts need to be negotiated in order for the consumer to take advantage of it. It just cost x amount of tokens.
Again these are very basic examples of the various pricing models in the market. These can be tweaked and augmented to come up with a compelling pricing model for your service.
Each one of your APIs may have a different pricing model. Again it really depends on the type of services you are trying to price. Another aspect, especially for enterprises with a large customer base across different market segments, is discounting for each customer segment. How you will fit that into your pricing model? Even smaller corporations will need to consider how discounts will work for their APIs. This will have an impact on the billing platform you chose.
You need to build the invoice and determine who is responsible for paying the bill. You really need to think about how are you going to structure your developer community. Typically companies leverage API management platforms like Akana’s API Management platform to manage their APIs. In an API management platform, for simplicity sake, you generally have three entities at work: the APIs, the Apps and the App Developers. The App Developer registers with the developer portal, creates a representation of the app that is going to consume the APIs and then subscribes to the API in order to begin consuming it. An App Developer can have many apps registered in the system each serving a different business purpose. Each App can be consuming multiple APIs. Multiple developers can team and work together on a single App.
The question becomes who and at which level do you want to invoice. Again these are simplified scenarios to illustrate the options:
- The Developer Level - All API subscriptions for all apps, roll up into 1 invoice per Developer. The developer who create the Apps gets billed in teaming scenarios
- The App Level - All API subscriptions for each App, roll up into 1 invoice per App. The developer who created the App gets billed in teaming scenarios.
- The API Level - All APIs have their own invoice. The invoice can go to the developer who owns the Apps or can go to the developer who created the subscription to the API for the App.
Another question you need to tackle is what actually appears on the invoice? Will you be like a mobile phone bill and see each API call and text? Or will it be a round number estimate? This will depends on the metrics you use and you pricing model.
As you can see you have choices to make and this can get complex very quickly. It can have an impact on how you structure your pricing model as well. My recommendation is to keep it as simple as possible. Always ask yourself if it is really necessary or can you make it easier for your consumer.
Collecting and Tracking Payments
Collecting and tracking payment is another interesting and complex topic. Again, a lot of how you do this depends on the business model for your APIs. Is your service the type that a customer can just enter a credit card and begin using? Or do you need a more complex process for on-boarding a customer?
You also need to think about who is going to process your payments, is it automated and secure? How are you going to manage and keep track of the transaction, and what are you going to do with failed payments. Are you going to make the invoice and payment history viewable from the API management platform developer portal? Again at what level is the visibility of the invoice going to be?
Akana's Integration with Billing Platforms
As you can see, billing is very complex from establishing pricing models, to invoice structure, to processing and managing payments. Each company that Akana works with (read about our customers here) has their own unique spin on billing. Every company is trying to innovate and disrupt the current market. Because billing is so complex, companies leverage billing platforms that take care a lot of the complexity for them.
Some of the companies we work with are retrofitting existing billing platforms while others are leveraging cloud based billing platform such as Aria Systems, KillBill.io, Zuora and Recurly. The spectrum of capabilities available in a billing platform varies widely amongst the traditional enterprise billing platforms and the top cloud billing platform vendors. You really need to take a look at what your requirements are for your pricing, invoicing and payment collection to make a selection.
Akana’s API Management Platform's API licensing and subscription model is very dynamic and easily configurable to the most complex enterprise licensing structure. This licensing structure is then mapped to the pricing and invoicing strategy you configure in your billing platform. The Akana platform can integrate with billing platforms that expose an API. This allows for complete workflow automation and a seamless user experience for your API consumers as they find, subscribe, consume and manage their payments for your APIs.
An example integration with Aria Systems is available on the Akana GitHub repository. In this example integration we used a tiered subscription pricing model with a freemium offering and overage charges. We are invoicing at the App leveling - all APIs subscribed to are rolled up to the app and the App Developer who created the App is responsible for the bill.
Yes, API billing is complex, but if you know the challenges and what to look out for, it can be made simple.