Our enterprise clients frequently ask how to develop a paid tier for API access. The first question we ask is whether the enterprise's existing partners already have access to an API at no cost or whether this is a net new API product release that the company wishes to monetize.
Certainly, the trickiest problem to deal with is charging existing customers for access to an API product they’ve previously consumed for free. In general, our advice here is to proceed with great caution, as changes like this in B2B can be quite disruptive. The right solution for any specific situation depends a lot on the details, but in general, our advice is to grandfather existing accounts at no cost for an extended period if you can afford to do so and to handle communications around the change very carefully. In some cases, it may not be worth the disruption ever to force legacy customers to move to a paying plan and to focus solely on converting new customers to your paid plan.
If you find yourself in the quandary above and would like help with your specific situation, please reach out. We’d be happy to review the details and provide advice based on our work with other companies who have made this transition.
For the rest of this article, however, I will focus on the different levers you can pull to create a paid tier of API access for net new customers. First, you might be asking, do I need a free tier for access to my API? While there are some exceptions to this advice...
💡 In general, we suggest that customers offer a free tier for their API as this lowers the friction of adoption and allows interested partners to develop a basic integration and demonstrate the value of the API before being forced to move to a paid subscription.
(and in case you are wondering, this advice is consistent even in industries like healthcare or financial services where B2B sales models are prevalent and regulations around data privacy are high)
Typically, the most obvious lever in any paid product is limiting the number of calls or the frequency of calls (i.e., enforcing limits on transactions per second / minute/hour) that are possible within the free tier. Although it is obvious, it is also typically quite effective as a lever to promote upgrades from free to paid access.
In industries / products where real-time data is more valuable than aged data (and where the data changes frequently), this is a great lever to use to encourage users to migrate to a paid version of your API. As an example, under this pricing strategy, free users would get access to data updated at the end of the previous day, whereas paid users get real-time data generated at the time of the API call.
By setting a limit on the number of records that are returned in any call, you can limit the utility of your product in free plans and promote an upgrade to paid plans for power users who require larger datasets in each call. While certainly savvy clients could work around limitations like this with more development, under a proper pricing strategy, it will make more sense to upgrade to a paid plan than to develop around the limitations in a free plan.
Almost all Enterprises will require a support contract and service level agreement for an API integration that will be used in a production system. By limiting access to support & Enterprise SLAs to your paid plans, you encourage business users to upgrade before they are ready to move your integration into production applications.
For products that involve clients sending data to your platform via API, your free tier should offer very limited data retention as this will limit your costs to operate the free tier and create another strong incentive for clients to move to your paid product tier. The advantage of a pricing lever like this is that it has no practical limitation on potential customers testing your application’s full functionality, but will prevent real business use without migrating to a paid plan.
As you can see from the examples above, there are many strategies you can leverage to create a functional free tier for your API product while also providing a strong incentive to upgrade before the API usage moves into a production scenario. These are five of approximately 15 potential levers we review with our clients who are considering monetizing an API catalog.
With these strategies in mind, you may be thinking about how to establish a price for your first API-based product. If so, this article will help to get you started.
