How to Reduce 3rd Party API Costs: Part I

How to Reduce 3rd Party API Costs: Part I

In this post, we will delve into understanding API business models and key factors that affect their costs and pricing. This is the first post in a series of 3 consecutive posts on how to reduce 3rd Party API costs.

Eyal Solomon, Co-Founder & CEO

Eyal Solomon, Co-Founder & CEO

July 11, 2023

API Costs

Costs associated with 3rd party APIs can have a significant effect on businesses, a trend that is only expected to grow as more companies become reliant on third-party APIs. Without proper visibility and controls on API consumption, businesses may find themselves facing unexpected or inflated costs when the monthly billing arrives. 

We've witnessed recent examples, such as Reddit's decision to introduce pricing for its once-free APIs, which caused quite a stir among users. Apollo, a popular third-party Reddit app, reportedly faced skyrocketing costs, with 7 billion requests in a single month potentially translating to a monthly expense of around $1.7 million or $20 million annually. That’s becoming increasingly common, especially in the wake of Elon Musk taking over Twitter. Similar to the Reddit situation, Twitter started charging for API access, shuttering dozens of third-party apps. Just how much? Small packages are priced at 50 million tweets for $42,000 a month, while higher tiers give researchers or businesses access to larger volumes of tweets—100 million and 200 million tweets respectively—and cost $125,000 and $210,000 a month.

In this blog post, we will explore the various pricing models adopted by API providers, discuss the key factors influencing API costs, and provide actionable tips to optimize and reduce 3rd party API expenses. By implementing these strategies, you can effectively manage your API budget and ensure that your API usage aligns with your financial objectives.

Types of API Pricing models & Factors Affecting Costs

Pay-As-You-Go, or Metered Model & Risks

The Pay-as-you-go or metered model is a pricing strategy widely used for external API consumption, by which users are charged based on actual usage of the API services. However, API providers that offer Pay-as-you-go pricing typically include those who cater to a wide range of users and applications, making it challenging to predict the exact usage patterns. 

Take Twilio for example; As a leading cloud communications platform, Twilio enables developers to integrate messaging, voice, and video capabilities into their applications. They charge users based on the number of API calls made and the volume of messages or minutes used. Another great example is the Google Maps API. While Google provides a pricing calculator on the website where you can estimate the costs based on your expected usage, the pricing structure includes factors such as the number of API requests made, the number of map loads, and any additional services or features utilized within the API.

Subscription Model (Flat fee) & Risks

The flat fee or subscription model employed by API providers involves charging customers a fixed amount for access to the API service over a specific period, typically on a monthly or yearly basis. Under this model, customers pay a predetermined fee regardless of their usage volume. 

The subscription model offers simplicity and predictability however, there are risks associated with this pricing model: One risk is the potential for customers to pay for resources they don't fully utilize, leading to inefficient cost allocation. Additionally, if the subscription fee is not adjusted appropriately to reflect the value or resources consumed by different customer segments, it may result in overcharging or undercharging.

Tiered Model & Risks

The tier pricing business model adopted by API providers involves charging customers based on different tiers or levels of service. Each tier corresponds to a specific set of features, usage limits, and pricing. Customers can select the tier that aligns with their needs and pay accordingly. 

While the tiered pricing model offers flexibility and scalability, there are several risks associated with it, one for example would be the selection of a lower-tier plan to minimize costs, which could lead to increased strain on resources if they consume more than anticipated. Another risk would be the challenge of accurately predicting customer usage patterns, which may result in underestimating or overestimating the demand for different tiers. Additionally, customers may face difficulties in accurately assessing their needs and may have to upgrade or downgrade their plans based on usage.

How to Optimize API Costs

Start by Estimating Costs

Estimating API costs can be challenging, especially when usage patterns vary, usage may fluctuate . Lack of visibility into usage can lead to cost overruns and unexpected billing surprises. That is the same reason why you may end up going for the wrong tier (assuming it’s a tier based API).

Code bugs, particularly ones like code loops calling the same API repeatedly and missing disabling feature flags around third-party APIs, can lead to increased API costs. Let's explore these examples. When a code loop unintentionally calls the same API repeatedly without appropriate termination conditions, it can generate a large number of unnecessary API requests. Each API request typically incurs a cost, especially in scenarios where APIs are charged on a per-request basis or based on data transfer. The excessive API calls caused by code loops ultimately lead to higher API costs.

Feature flags for example, are used to enable or disable specific functionalities within an application. If the feature flag to disable a third-party API integration is missing or not properly implemented, the API requests associated with that integration continue to be made, even when the functionality is not required. This leads to unnecessary API calls and subsequent costs, as the integration consumes resources and incurs charges even though it is not actively used.

Alerts and thresholds

By setting alerts and thresholds, you can monitor your API consumption and receive notifications when certain predefined limits or thresholds are exceeded. This allows you to quickly identify any abnormal or unexpected spikes and to investigate the root cause, such as inefficient API calls or potential misuse.

It boils down to having proper costs control and budget management, which by setting thresholds based on your budget or anticipated usage, you can proactively manage your API consumption and prevent excessive usage that may result in unexpected costs. 

Tracking the provider’s SLA

By actively tracking and enforcing your provider’s SLA, you can ensure that the API provider meets their obligations and holds them accountable for any breaches. This can help you recover costs or negotiate better terms with the provider.

Furthermore, when entering into contracts or renewing agreements with API providers, having a clear understanding of their SLAs allows you to negotiate favorable terms that align with your cost optimization goals. 

Optimization middleware

Take for example API caching - a technique that involves storing the response of an API request and serving it directly from the cache instead of making a new request to the API server. The cached response is typically stored in a cache store, such as in-memory cache or a distributed cache, to enable faster retrieval.

Implementing optimized middleware can lead to more effective consumption. To implement effective caching start by identifying cacheable responses: Analyze your API responses and determine which ones can be safely cached. Responses that are static or have a long expiration time are ideal candidates for caching.

Always make sure to implement appropriate caching mechanisms. In-memory cache like Redis are useful for fast, low-latency caching, while distributed caches like CDN (Content Delivery Network) caching are suitable for global scalability. Also, Pay attention to the cache headers: It’s good practice to implement cache according to the response headers , such as "Cache-Control" and "Expires", which instruct the client and intermediary caches on how to handle caching. This allows proper control over cache expiration and freshness. 

Preemptive Mechanisms

An API circuit breaker is a great example of preemptive controls. Circuit breakers are a design pattern used to enhance the resilience and fault tolerance of applications that rely on external APIs, by protecting the application from cascading failures. Using a circuit breaker can be particularly helpful in preventing cascading API usage costs by avoiding unnecessary API calls. By stopping subsequent requests, the circuit breaker avoids incurring additional usage costs during the API's degraded state. 

Some critical steps to make circuit breakers effective include - defining thresholds for response times, error rates, or other relevant metrics to determine when to open or close the circuit breaker; Implementing smart retries: When the circuit breaker opens due to a detected failure, incorporate an intelligent retry mechanism. Instead of immediately retrying API calls, introduce delays or exponential backoff strategies to gradually resume calling the API when it is likely to have recovered.

Closing Notes

To conclude, there is so much to optimize and make more efficient when it comes to reducing API costs and calls. By implementing even some of the strategies outlined, such as tracking usage, implementing optimization middleware caching and or utilizing preemptive mechanisms like circuit breakers, businesses can take proactive steps to reduce API expenses. 

As experienced engineers, who’ve tackled endless 3rd party integrations issues, the team at Lunar is on a mission to ease these pains for other teams. We invite you to connect with us at info@lunar.dev to discover more about our expertise. Share your specific use-case, and our team of experts will work closely with you to design the optimal mechanisms for gaining control and optimizing your API consumption costs.

Ready to Start your journey?

Manage a single service and unlock API management at scale