Provision Paid Plans
One of the most popular ways to monetize an API is by defining subscription fees for usage of the API. This section focuses on the use of application plans to provision pricing tiers. It is also possible to apply pricing rules at the account and the service level, and these topics are covered in advanced guides.
At the end of this section you will understand the pricing options for application plans and be able to setup a paid plan.
Step by Step
Step 1: Choose your Pricing Model
The first question is to decide how to differentiate between the tiers in your pricing model. The answer could be one of, or a mixture of:
- Volume / Usage
- The most common way to scale between tiers is based on volume because this is usually strongly correlated with value to customer, as well as cost to serve. You can apply this on a global hit count for calls on the API, or with more granularity at the method level
- Depending on the tier, you may enable or disable access to parts of the API. This is a good approach to distinguish standard and premium levels.
- For any other resources which provider value to the customer, or are a cost driver in your infrastructure, you can meter out access. Examples are bandwidth consumption in GB, number of users, or transaction values.
Once you have decided on your pricing drivers, you need to also decide the pricing rules. The options include flat rate subscription, variable rate, and one off upfront charge. If you use volume of hits or resource consumption for your differentiation, then clearly you will have an element of variable rate pricing. All three of the pricing drivers are also compatible with the one off, or monthly flate rate subscriptions.
Step 2: Setup an Application Plan with your Pricing Rules
First you either create a new application plan or edit an existing plan. As part of the creation step you can enter any upfront charges or flat rate subscriptions.
In the edit application view, you can enter/modify the upfront charges and subscriptions. Next you setup up the pricing drivers that you chose in step 1. If some of the drivers already exist as metrics, then you simply edit the item:
- Volume drivers: are applied at the level of the global hits metric, or for individual methods under hits. Multiple pricing rules can be applied to any metric. Note that the hits calculation is cumulated over a one month billing cycle
- Functionality drivers: are set by enabling or disabling the metric for this plan
- Resource drivers: are similar to volume drivers, but are applied on custom metrics
Once you are finished with setting up your pricing rules, be sure to click “update application plan”
Step 3: Create further Pricing Tiers
It is fine to define an API paid plan with one single application plan. Usually this would be the case if all your pricing rules are defined with volume or resource drivers. However if you want to offer separate plans for the different segments of your developer community, you will need to add more application plans. The easiest way to do that is to copy the first application plan from the application plan overview page. This way you have a pre-populated plan with all the existing metrics and pricing rules. Of course the more care you take to create a full plan the first time, you more time you will save with the plan copy feature.
Step 4: Provision the Paid Plans
In order to provision the plans, your developers must create new applications, and select one of the new paid plans. You can also do this on their behalf from the admin console. For any existing applications it is also possible to change from an existing plan to one of the new paid plans.
In conjunction with flat-rate pricing plans it is very common to differentiate the different tiers through varying rate limits. The steps to do this are explained in Provision rate limits