How to Monetize Your APIs: Choosing Your API Monetization Stack
Monetizing an API isn't easy, but with the right tools, you can build a product and deploy ASAP. Learn about assessing which stack fits your API needs.
Join the DZone community and get the full member experience.
Join For FreeThe technology you choose to start your project with determines what your product is capable of now and what it will be capable of in the future. Finding the right stack to build on top of is one of the biggest engineering challenges you can face. Picking a stack that allows you to build a product and get to market rapidly is great unless that same choice limits the scalability and features of a product in the future. Pick a stack that is well beyond your current and future needs, and this could lead to difficulties building the initial project you’ve set out to build. A balance must be struck between your current needs and the needs of your product and customers in the future.
When it comes to making money from your APIs, picking the right stack can help you get up and running quickly and allow for flexibility for your business and its customers. Let’s take a look at a few ways to assess which stack best fits your API monetization needs.
What Is API Monetization?
Everything runs on APIs, and the API economy continues to grow. Do you have an API product that you think other individuals or companies may want to use? Then, usage-based billing and API monetization are something you’ve likely thought about. When we speak of API monetization, we are looking at how we can bring in revenue from our APIs, whether through charging per user, per API call, or another metric. If your business model doesn’t include using your API resources to drive additional revenue, you could be leaving cash on the table. API revenue could be a very quick win, especially if you have public APIs that could be of use to other businesses.
How you charge for usage and when will depend on your billing model. You may make money by charging an API consumer after they have used your API through a post-paid billing model. You may also decide to charge an API consumer up-front for usage in a pre-paid or pay-as-you-go type billing model. There are many different ways to make money from your existing APIs and from the ones that are being built.
Once you’ve decided that you want to use your APIs to generate further revenue, you must build a solution to do just that. The solution will likely have a few moving parts, and each of these parts will play a crucial role in your API monetization stack.
What Does an API Monetization Stack Look Like?
In its simplest form, an API monetization stack has 2 components: your API and a billing provider. Unfortunately, to make the combination of these work becomes quite difficult to implement. A lot of customization and expert knowledge are required in order to make this work efficiently and accurately.
A more practical approach is to break the solution down into 3 parts: your API, a platform to track API usage, and a billing provider. Let’s look into the role of each of these components.
1. The API
The API is where the value to users is going to sit. Here, when we talk about “the API,” we are referring to everything to do with the API, including securing the API, rate-limiting, transformations, etc. Usually, part of the API setup likely includes some API management layer, like an API proxy or an API gateway. Most modern businesses are using API gateways such as Kong, Tyk, AWS Gateway, or one of many other alternatives.
2. API Analytics (For Tracking Usage)
As the API is being used, you’ll want to gather metrics about that usage. Since the analytics platform is seeing API consumption metrics around every API call, it makes sense for this to be the system of record for tracking usage and sending it to the billing provider.
3. Billing Provider
The billing provider will receive usage amounts for each customer, tally up the amounts over the billing period, issue an invoice, and collect the amount owing.
Choosing Gateway or Proxy for Your API
When choosing a gateway or proxy for API management, it’s important to understand exactly what functionality you will be needing. Almost every gateway on the market has some differentiators which may make it more or less suitable for your use case.
One thing is for sure, using an API gateway will make securing and managing your APIs much easier than doing it without. Most gateways support a wide variety of authorization and authentication protocols to control API access, tools for generating and managing an API key, great support for rate limiting and quotas, and other features such as the ability to apply transformations to requests and responses. An API management platform also usually provides a developer portal so that API users can easily see which APIs are available and get access to them.
Although APIs can be managed without an API gateway or proxy, having one means that you can establish a more uniform way to secure and manage the APIs. Essentially allowing you to manage all of your API-related concerns under a single pane of glass. From a scalability and security perspective, there’s no better solution.
Popular API management tools include Kong, Tyk, AWS Gateway, Azure API Management, and many others. Each will have its own pros and cons, just like any other piece of software or infrastructure.
Choosing a Billing Provider
When choosing a billing provider, as with any technology you incorporate into your stack, you should be aware of current and future use cases and how the technology can support them. You should take stock of your product roadmap and map out the technical pros and cons of each solution. A great overall picture of the differences is mapped out here. You’ll also want to be aware of what it takes to integrate the billing provider with your current solution as well. Different providers have different ways to integrate, which can make them more or less suitable for your project. Another detail is to ensure that the billing provider can support your API monetization model.
On top of the technical requirements, there are a few other operational factors that should also go into choosing your provider. These factors are highlighted below.
Cost
For most companies, this will be the main factor outside of comparing the capabilities of the technologies. If both billing platforms will technically work for your project, the next focus will be on cost.
The cost of a platform could be calculated in many different ways. It could be done as a flat rate, percentage, or a mixture of both. You’ll also need to factor in the volume that you’ll be passing through the system since that can also lead to discounts which may make a certain provider more attractive.
Reporting
The reporting tools built into the platform can help the business side of an organization easily see the results of API monetization. Most platforms have a minimal amount of reporting, while others have extremely detailed reports available. If you’d like out-of-the-box reports versus homegrown ones, this should be an important factor.
Customer Support
If an issue does occur, it’s great to know that the provider can provide quick support to remedy the problem. You’ll want to make sure that you look at different support packages that the provider offers, what the SLA is for turnaround on minor and major issues, and also look at some customer reviews to see if existing users are happy with the support.
Billing Meters
Billing meters are the heart of the monetization solution. A billing meter allows you to describe how you want to charge users and specify that criterion. These could be criteria such as billing on a specific endpoint, a specific part of the request, a response code, a combination of all three, or any other criteria imagined.
Once the billing meter is set up, it will report this usage to the billing provider at scheduled intervals. This can be done in a matter of minutes and takes absolutely no code to create.
Governance
Governance can allow you to block calls when an invoice is overdue or, if you’re doing a pre-paid setup, can block an API consumer once they have run out of credits on their account. Again, all of this can be done with no code, no engineering support, and can go live in a matter of minutes.
Governance rules can be set up by configuring a filter that suits your exact needs and specifying what you would like to override the response with. For instance, if a user has run out of credits to use the API or has an overdue invoice, you may return a 402 Payment Required status along with a JSON body that goes into more detail.
Behavioral Emails
Automated emails become handy when a user is going into the next usage tier, getting close to a rate limit or quota, or is out of credits. Of course, there are plenty of other scenarios where automated emails can help as well. The great part about using behavioral emails is that they keep customers informed about key events while also reducing the support and sales team burden, whereas, in the past, they would need to directly reach out.
Alerts
On top of behavioral emails, it also may make sense to send notifications to different internal teams based on a company or user’s actions. For this, we can set up alerts to be triggered by specific criteria. These alerts can be delivered through email, SMS, and alternatives like Slack, PagerDuty, or a custom webhook.
For monetization, this might consist of letting the sales team know that a user is ready to move to a new plan based on their volume or behavior. It may also mean sending your finance or collections department an alert letting them know that a delinquent customer is trying to access an API.
Getting Started
Monetizing your APIs is a complex project to undertake, but it doesn’t have to be hard. Along with a great API strategy and robust API design, by using reputable and proven technologies to get you to market quickly while keeping quality high, you can quickly drive revenue from your APIs. Choosing the right stack for your monetized API is crucial for the needs of today but also for making sure that you have what it takes to expand into tomorrow confidently.
Published at DZone with permission of Matt Tanner. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments