[*Jason Cumberland*](https://www.linkedin.com/in/jasoncumberland/)*Jason Cumberland**, CPO and co-founder of API and data monetization platform *[*HyperCurrent*](https://www.hypercurrent.io/)*HyperCurrent**, contributed to this post.*

In our last article on [how to get started with API monetization](https://konghq.com/blog/api-monetization-strategy)how to get started with API monetization, we laid out how to build your [API monetization strategy](https://konghq.com/blog/learning-center/what-is-api-monetization)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.

### **1. Speed**

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](https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales)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](https://docs.konghq.com/hub/kong-inc/proxy-cache-advanced/)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](https://docs.konghq.com/hub/kong-inc/rate-limiting-advanced/)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.

### **2. Security**

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](https://konghq.com/webinars/success/Top-3-Strategies-to-Secure-and-Govern-Your-Microservices)key areas worth consideration. The webinar linked covers them, and we'll list them briefly here:

• - **Confidentiality and Integrity**: Ensure encryption of APIs is applied and validate payloads as necessary.
• - **Authentication and Authorization**: Ensure you're able to identify a consumer and only allow them access to APIs and data they're entitled to.
• - **Availability**: Plan for adverse events and take appropriate mitigation countermeasures.

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.

### **3. Visibility**

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:

• - Usage patterns: Spikes, seasonality, order of execution
• - Latency patterns
• - Failure rates
• - Suspicious usage patterns
• - How often usage limits are met by users
• - More specific nature of requests, perhaps at the field level.

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:

• - Report SLA performance by customer (success rate and response time at a minimum)
• - Analyze revenue generated by API product bundle, or by API for individually monetized APIs
• - Be alerted to customers who are approaching their quotas so your sales team can initiate an upsell conversation
• - Monitor conversion rates from freemium API products to premium API bundles
• - Monitor usage of APIs for newly adopted customers to introduce customer success teams early when the metrics indicate adoption challenges
• - Be aware when customer usage drastically changes, down or up, so that you can predict customer churn and inform customers of unexpected spikes in demand before they receive a large unexpected invoice

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.

### [](https://www.linkedin.com/in/jasoncumberland/)**4. Usage**

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](https://konghq.com/blog/rest-vs-grpc-vs-graphql)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](https://konghq.com/blog/customize-kong-developer-portal)DevPortal.

### Conclusion

We previously talked about [how to get started with API monetization](https://konghq.com/blog/api-monetization-strategy)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*](https://www.hypercurrent.io/)*HyperCurrent** can help you build and implement a winning strategy. Set a foundation for API monetization success — check out *[*Kong Gateway*](https://konghq.com/kong)*Kong Gateway**, the world's fastest and most adopted API gateway. *