API Monetization strategies

As discussed in the previous article, API monetization is a very powerful tool and currently, any organization that has any understanding of APIs and can buy Google Ads are “API monetizers”. Many weak players can be identified by having a weak, unknown platform (if any) and a “silver bullet” to solve all your API monetization problems with 1 generic solution.

In this article, we will take a deeper look at API monetization models and how they can help your organization.

Set your goals 

Now that you have started taking your API seriously and consider it as a product you need to evaluate 2 extremely important points:

• What are the resources I can invest in the API?
• What is the outcome I expect?

Once tangible goals are set (100$ revenue after 2 years, 100 subscribers, 90/10 ratio of free/premium users, etc.) you can choose the correct strategy and measure the required resources. By choosing one or many strategies and combining them on the product roadmap you will be able to predict (or try to predict) your revenue, required improvements, and their cost as well as maintenance costs. To select the correct strategy you should always do deep financial modeling and combine that with knowledge of your field and understanding of your client’s habits. The result of this activity will allow you to adjust your goals, their minimums and stretches as well as to define your market entry strategy (e.g., start slow, but steady or penetrate huge market share quickly as your cheap solution works only on the scale or any other approach that works for you).

Free 

There might be cases when you want to simply give your product away for free. There are many reasons for this – you have created some random API and wish to do good for the world, show off your skills or this is an API that your clients can get for free as an added value to your paid service. With this option, you always need to think about your long game as this strategy will never generate any direct income (see the word “free” in the name). What it can generate are long-term gains in additional business, new opportunities, or opportunities to meet like-minded people to create future opportunities. To choose this you must be either very generous or have a good plan for the future.

There have been cases when companies are giving away free products and then for some clients it becomes a paid product, but such a step needs to be strictly evaluated and a realistic % of paying customers should be evaluated both short and long term. Some strategies may include:

• Free API should become the general process in enterprise and when it becomes paid API, it will be very expensive to replace
• Your free API is so good that other competitors naturally die off. Once you make it paid product, enterprises will have to wait a long time until competitors develop the same product to your level (and cheaper than you)
• Rise the price high enough to earn, but low enough so there is no initiative to change to a different vendor

Consumption-based pricing

Each API call is considered a separate transaction and the user pays for the number of calls or size of the data transfer. Many clients prefer this pricing model as theoretically each one has access to unlimited resources, but they are paying for services they use. With this model, you need to have enough resources to scale immediately on request and to track all the consumption.

Pricing models can differ according to the client’s needs as well as your capabilities and payments requirements:

1. Pre-paid – client buys “credit” and can consume it over time according to pricing
2. Post-paid – client uses the API and after a period of time invoice is sent (e.g., once every month)
3. Post-paid with limit – once the client reaches the limit, API consumption is stopped or limited

For consumption-based pricing you need to be very careful about support – you should include some percentage in the consumption costs, but this model comes with a downside – it’s harder to predict future revenues as clients may decide not fully use your services and subscription-based APIs tend to be extremely easy to set up and the same level of hardness to jump off the API and switch to an alternative. With this model, it’s important to have very good self-service, documentation, and examples to decrease possible human-to-human support interactions, endless internal emails, and meetings as well as an added cost for implementing and teaching AI support robots.

Subscription 

This is a simple flat subscription fee for access to an API or a set of APIs. This is most appropriate for APIs that deliver useful functionality but not large quantities of data which might generate unpredictable costs for the provider’s operation.

Tiered product

A tiered product is not only a marketing tactic it is also a tool to validate your product. In essence, it means that you have a single product, but the functionality of each tier is limited. From a user point of view, you can offer to each client the possibility to select the functionality it requires without additional things that may never be used. This approach has been used for decades by cable companies where a consumer could buy a pack of channels that are available. By paying a bit more customers can get even more channels. The same approach is used for tools like Microsoft Office 365 or JIRA where companies can choose which pack is most suited for its operating model and as the company grows, the requirements grow and so do the needs for additional products. If in simple startup mode you could live with basic online tools then advancing to multi-million corporations may require specific tools for project planning, data analytics, and many more. 

From a product point of view, you can always analyze the tier and understand which product groups are underperforming or where you have too many costs compared to the functionality you provide. If one tier is overperforming and another underperforming against the goals you have set for each tier (number of users per tier, average upgrade to higher tier, revenue from each tier, etc.) you can either gather feedback on what is missing to switch, what functionality is missing for users to get the value for the money or what functionality is never used in a particular tier so you can decrease the operational costs for maintaining it.

After long and extensive A/B tests, 3 tiers are the optimal number of tiers. More than that and people can’t fully understand the information and compare the features. Splitting into 3 levels seems a very natural approach:

• The top tier is the feature-rich tier that establishes reference for maximum value
• The middle tier is your money maker and should bring in most of your revenue thus selecting which functionality to enable is very important
• The low tier is there to lure people in (either for them to see how awesome your product is and throw money at you or get frustrated with key functionality being in the next tier and then upgrading). In any case – you must find the balance between giving out not enough and giving out key features so users don’t need to upgrade ever.

Tiered product requires heavy data collection, analytics, and possibilities to experiment (adding API building blocks for new features, changing how APIs work, etc.) as well as good API lifecycle management capabilities and user management.

Points based product

A useful tool that gives your clients extra initiative to stay loyal. This approach has many pros and many cons. From a technical point of view first, you need to understand how loyalty points will work with an API. It is not as easy as in a regular store (buy for 10 euros and get 10 cents on your card) as you will have to combine this strategy with one or many other API monetization strategies and define the rules for loyalty (e.g., if the client is on the lowest tier, but refers 10 new users in one year, the client gets to use the middle tier for one year for free).

This approach also needs to have a good back-end that allows configuring the rules, allows running analytics and evaluating the offering and that can easily reuse API building blocks for better products. Some companies subscribe to services that manage loyalty programs, but one of the first rules in such engagements is easy to access to the digital product (API) and extremely good analytics.

Affiliate

A marketing method that enables users to promote or sell products by other vendors using their specialized links. Affiliate marketing (for API products) requires you to enable 4 main points:

1. Very precise and full-proof referral program. This is the most important point as affiliates who feel scammed will not want to work with you. You need to have a simple and robust approach that allows the collection of your target information (e.g., sales made using an affiliate link, new users using the affiliate link, etc.). You should think of a microservice that is always connected to the main API and always on the watch for affiliates.
2. Suitable for 3 types of affiliates. You need to understand that there are many types of affiliate marketing and part of your strategy is not only to define the product but in the case of using affiliates, to define them:
   1. Unattached – affiliates that have no connection to your API and mostly require simple pay-per-click functionality. For these clients, you need to have your setup as simple as possible and informative enough so the affiliate would not leave instantly due to your overly complicated product
   2. Related – affiliates often are part of the same niche you are, but aren’t working directly with your API. They can be technology or data aggregators, marketplaces, etc. Specifics for this type are mostly to provide high-quality documentation, feature descriptions, and options.
   3. Involved – affiliate that is directly involved with your product either by working with it or helping to improve/deliver it. For this group, it’s very important to have your API easily integrated with affiliate systems. This type can be very demanding from a technological point of view, but very valuable as a brand promoter.
3. End user management. Not only is it important to manage your affiliates, but you must also have API management functionality that allows tracking end users, mapping them with the affiliates, and managing their APIs (e.g., different access levels, different functionality, etc.).
4. API lifecycle management. With affiliate marketing, you need to have full API lifecycle management functionality. Both affiliates and end-users need to have the latest APIs, availability, and any other functionality. It’s unacceptable to update an API, but not to remember to update user manuals and leave end-users in the dark. Nothing kills good statistics better than not working on solutions on the end user’s side

Revenue share and Paid partner

Revenue sharing is a common approach and can be a great asset in the API economy. With this approach, revenue is shared between two or more involved parties. For example, your API is exposed on a partner site and your service is used as added value service, but instead of the partner paying a subscription or based on consumption, you share the revenue as without each other you would not be able to deliver any value (e.g., hotel booking app adds your car rental API – they get the extra added value and revenue stream while you open business channels that could only be reached due hotel reservation apps popularity).

In most cases, if the enterprise is big enough, they could be willing to pay for your services, but no revenue sharing. Similar to revenue share you would provide (often very targeted) services, but in this case, your revenue is determined by contract (like fixed, fixed + sales %, or other). 

A good pre-requisite is a very good quality dev portal, documentation availability, and great analytics integrations. APIs need to be packaged and distributed in a way that delivers trust and clarity to possible partners. Often people don’t want to play with others who can’t clean up their rooms. 

Content acquisition and syndication

The practice of buying content for redistribution and further modifications. As a content provider, you must have good APIs (and sometimes MFT solutions) to provide your content partners with frequent, valid, and defined data deliveries. This option heavily depends on business agreements requiring a very interesting combination of API specifications – API should remain static, but with good lifecycle management behind it and very flexible in adapting business rules, limits, and other key points.

Business expansion, mergers, and acquisition 

Some enterprises decide to simply buy competitors or companies that would supplement the original product. Depending on planned expansion, the company needs to align its API strategy accordingly. Such actions are taken (but not limited to) in many cases to:

1. Buy missing technology – sometimes it’s cheaper to buy and adjust existing product
2. Increase team capacity – competitors working with the same tools and the same area joining forces may be a good idea
3. Buy additional products – if subscribing on paying for usage is too costly in the long run, this can be a trigger for business expansion (assuming that the company is ready to enter a new business area or a slightly different one)
4. Stop competitors

This point will genuinely be very complicated and will require lots of financial planning and execution. Often it would require integrating a lot more than one API. If a company is big enough, you will have to deal with its internal and external systems, clients, suppliers, etc. You can make a smart decision and invest in a strong, reliable, and proven platform that will speed up both the merger and your general process, help decrease costs and implement a full API economy.

There are many different solutions, and many subsets that were not even mentioned here, but this should make a good general understanding of many different strategies you can choose and combine. 

Each solution requires a unique approach and we would be happy to become your partner to support you in this hard and never-ending journey.