Jason Cumberland, CPO and co-founder of API and data monetization platform HyperCurrent, contributed to this post.
In our last article on how to get started with API monetization, we laid out how to build your API monetization strategy and avoid common pitfalls that occur when trying to get to your first minimum viable product release. In this article, we'll focus on the technical elements and API monetization best practices that will lead to a monetized API product that is likely to grow and delight your customers.
Here are four key considerations to keep in mind to build your technology stack in a way that maximizes your chances for API monetization success.
Given a choice, APIs consumers will want a fast API instead of a slower one. If an API is involved in an eCommerce end-user experience, it’s observed that every millisecond counts.
APIs involved in IoT, streaming, gaming, and other time-sensitive applications also require low latency. It's hard to imagine an API where being slow is preferable. Therefore, it's a good practice to build APIs with predictable performance in mind.
Latency is one measure of performance as it relates to speed; throughput is another as it relates to scale. Throughput is therefore a function of the scalability of APIs. Caching can be used to improve latency and throughput, but it's not always possible.
Planning for scalable APIs is ideal. For APIs that can no longer be scaled, using rate limiting will be necessary to ensure predictability for end-users.
When monetizing APIs, you can use higher rate limits, or lower latency, thus a higher quality of service, as an incentive to upgrade to higher-cost plans, which helps your customers to self-select into performance levels appropriate for their use case.
For example, free versions of APIs can be throttled, whereas bronze, silver, gold, and platinum tiers may have higher thresholds or no thresholds at all.
A natural bi-product of scalability is fault tolerance. If you're able to make your APIs satisfied by multiple deployment regions, you can fail over from one region to another should an adverse event take place.
Remember, every minute your APIs are offline you're not only losing revenue, you're potentially losing future revenues as your users look for alternatives for the perception of a service with sub-optimal reliability.
Note that in some instances, your regions might not be compatible with each other. Consider an EMEA deployment where you have to have GDPR compliance. This may not failover to the USA deployment, if you have one. Therefore you will need a minimum of four deployments, with at least a pair for each set of compatible regions.
In short, APIs need to have an SLA that users can rely on.
Productized APIs get more attention from attackers that want to gain access to a paid resource at no cost. Monetized APIs are also likely to be marketed, thus giving them additional attention that warrants a more aggressive security posture.
API consumers will have expectations about how the data being sent or received will be secured. Information security is a rather broad and complex topic. However, for the purposes of APIs, there are key areas worth consideration. The webinar linked covers them, and we'll list them briefly here:
Customer expectations are always high when it comes to information security surrounding APIs, but when your customers are paying you directly for access, the bar is that much higher.
To ensure rapid adoption of your API-based products, and minimize the time spent in security reviews, design from the ground up with these principles in mind, such that API consumers have confidence in the product they're buying.
Having good telemetry on APIs is an important ingredient in improving them. It also helps when designing new APIs. Put another way: "You cannot improve what you do not measure."
API product managers therefore need to have an idea about what constitutes good metrics for the APIs.
Perhaps it's latency targets, utilization targets, throughput targets, cost structure (compute perhaps), or end-user satisfaction. It's therefore important that some thought is given to the telemetry to be collected, perhaps including:
When dealing with internal or non-monetized APIs, monitoring the areas above are adequate, but when dealing with API monetization, you must ensure that your analytics extend into business value reporting. Specifically, best practice dictates that you have the capabilities to:
The key when developing your monetization strategy is to remember that you are moving from what is traditionally an IT and engineering function into the domains of product management, marketing, and sales.
Making this shift will stretch the capability of traditional API management metrics, so we recommend you define your requirements for business value reporting early in the process to ensure you choose a platform that provides visibility across all of these areas.
Last, but far from least, we look at what makes an API easy to use and appropriate to the customer segment you are targeting with each of your monetized API bundles.
Particularly when commercializing your APIs, it's important that you begin by defining the target customer for each of your products. Once you've identified the customer, you must document the user stories that detail the problems you're solving for that customer segment, and ensure that each of your APIs is designed specifically to fulfill that use case and to make your customers' job using your API as intuitive as possible.
The first area to review when considering your target customer is use case. It's important to design the granularity of the API to match your target customer use case. A very fine-grained API can be suitable for usage patterns where very specific and small functions are carried out. However, it can be inefficient for bulk operations, so knowing what your target customer prefers is critical.
Next, the protocol and the payloads of APIs need to be planned to be fit for their purpose. REST, gRPC, GraphQL, WebSocket, and even raw TCP all have their use cases. A good API design must take into consideration the needs, preferences, and use-cases of the targeted API consumer. (This article is a good reference if you would like more detail on this topic.)
Lastly, assuming a well-designed API is to be actually used, it must be documented well. Good documentation is concise, comprehensive, easy to understand, easy to find, and provides examples and answers to common questions. The most common way to meet this requirement in a way that is developer-friendly is by using a DevPortal.
We previously talked about how to get started with API monetization, including how to select the ideal API monetization strategy team and source ideas for your first product. With those strategies and an understanding of how to build your technology stack as covered above, you'll be maximizing your chances for success.
Currently working on API monetization? Kong and HyperCurrent can help you build and implement a winning strategy. Set a foundation for API monetization success — check out Kong Gateway, the world's fastest and most adopted API gateway.
Today, we’re announcing that Kong has acquired OpenMeter , the open source and SaaS leader for real-time usage metering and billing. OpenMeter’s capabilities will be integrated into Kong Konnect, enabling usage-based pricing, entitlements, and invo
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
In this article, which is based on my talk at VueConf Toronto 2023, we'll explore how to harness the power of Vue.js and micro frontends to create scalable, modular architectures that prioritize the developer experience. We'll unveil practical strate
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross