I Have A Bunch Of API Resources, Now I Need A Plan, Or Potentially Several Plans
I have some really amazing resources exposed as APIs. Everyone is doing it these days, and I have some good ones, now I just need a plan. You know, actually, I need several plans, that will help me expose these resources to the right people, while remain as much control as I need, and also generate revenue from these resources, tailored to whoever I am offering them to.
Starting With The Essential API Building Blocks
I want to allow anyone to access my valuable APIs, however I want to control exactly how much they can access, and even limit it to a free trial, and a small amount of calls upon the API. I am going to call this Plan A, also known as my freemium layer, meant to just wet the appetite of any potential API consumer. I ow have a basic level of access to my API resources, that anyone can sign up for 24/7, yet I get to dictate exactly how many hits on the API they can make, and who gets access.
Moving Beyond Plan A For My API Strategy
Plan A only gets me so far, I need to also be able to establish additional plans that help me cover the costs of my operations, and hopefully also generate some revenue from API access and usage. I need to be able to establish any number of plans that I will need to be successful. Each additional plan that I offer, lets call them plan B, C, and D, should have the ability to sign-up 24/7 without approval, possess a trial version option if necessary, and allow for charging of setup costs to get going--if I so choose.
Defining Usage Metrics That Are Meaningful To Me
All of my plans will start with these elements, but then should allow me to set any other metric I desire. I want to track on API call, by message, according to bandwidth consumed or stored, the time period in play, the scope of compute being applied, and much, much more. Any of my plans should be able to to measured in these units, or anything else I want to define. If an API plan provides access to a blog, product catalog, the requirements might be different than when I provide access to images, videos, podcasts or other heavy objects. I should be able to define the metrics, and set a price per metric that can be applied to each APIs I am making available.
Establishing Limitations For API Access
Each of my plans should have well defined units of operations (metrics), cost per unit, and volume pricing, but also should possess limitations of what can be accessed. I need to restrict some plans to a daily amount, limit server loads by only allowing a certain amount of requests, bandwidth, per second, minute, hour, day, week, or month. If I want, I should be able to leave API access open ended. How I define the access for each of my API plans, should be tailored exactly for my intended audience for each plan, with an infinite number of plans possible.
Which APIs Methods Are Available In Each Of My Plan(s)
No plans are created equal. Which API resources, and methods, and verbs, are available in any given plan is again, tailored to the intended audience of each plan. My Plan A allows limited reading from just a handful of resources for everyone, while my Plan C allows for reading and writing from a variety of API resources, designed for a specific group of partners, defined by me. My public facing plans encourage consumption of specific resources that I have crafted, while my partner plans encourage two way usage, incentivizing my partners to add, update, and curate information available via the API resources I have made available.
All The Variables I Need To Compose The Plans I Need
I can create as many APIs, and individual methods, and package them up into plans, and measure their access by call, bandwidth, storage, time period, compute, and other critical metrics. It is within my control to set limitations, and volume levels of access across these metrics, charging exactly what I need to incentivize API usage, while also covering the costs of my operations, and bring in a healthy bit of revenue in the door as well--I have a full toolbox of what I need to orchestrate my API driven business model(s).
Provide The Features My Consumers Will Need Along With Each Plan
Along with the access of API resources within each plan, I need to also bundle other features, like support, service level agreement (SLA), and other resources that consumers will need to be successful with integrations. Again, each plan should be tailored for the intended audience, providing the API access they need, while also makes sure all their adjacent needs are met along the way as well.
Providing Variable Unit(s) of Value For All API Transactions
Whether its an API call, bandwidth transmitted, or duration of resource usage, you have measurable units of value, where a price can be set, in a way that lets it be adjusted by volume, or each plan level. An API call might be one cent (for sake of discussion), but if you access more than 10K per day, it goes down to half a cent per API call. For partner plans, each API call might be 1/10th of a cent by default, with 1/100th of a cent if you access more than 10K per day. Each API has its unit of value, with the price for this unit of value variable depending which plan you are in, and how much you consume.
How Do We Know What Price To Set For Each Unit Of Access?
You have an API, but where do you even start understanding where to price this resource, which you feel is really cool and valuable, but might be completely meaningless to others. You can start by looking at competing API providers, and follow any precedent that has been set in the industry to date. Beyond following the lead of others, you can break down your own story, and dial in exactly what it costs to deliver an API, and set the price for the industry, and lead others.
What Did Cost To Acquire What Is Need For An API Resources?
Every API starts somewhere. What did it take to discover the idea for an API, negotiate or license its usage, or maybe you had to purchase some content, data, or access to a programmatic resources. Before you get to work developing an API, there will be some investment to bring an API idea to production.
What Has Gone Into Developing An API?
Beyond the acquisition of an API, like the API usage itself, this might be a two way street, it might not just be costs associated, but also investment from other partners, investors, or otherwise. What has gone into normalizing resources, designing and developing the database, server, and the API itself. Consider the network too--what will it take when it comes to network bandwidth, and what are the DNS considerations to manage traffic. Thanks to cloud computing, there are many ways to meter areas like compute, storage, and bandwidth, make sure and put these tools to work for you.
What Are The Realities Of What It Will Cost To Operate An API?
What are the costs associated with maintaining the central truth of an API, its definition? What are the hard compute, storage, and bandwidth costs associated with API operations? I'm sure you have a good handle on what these are. How much do you have invested in management, monitoring, security, and evangelism? There are a lot of costs to consider beyond the visible aspects of API operations, but there are also a lot of associated costs to operations that often get left behind like support, and the creation of additional resources.
Let's Discuss Who Will Be Access An API And Our Plan For Different Levels
Now we have a better handle of what goes into acquiring, developing, and operating an API, but who actually be accessing the API, and who do we need to offer different plans to, tailored for their relationship with me, and their unique needs. We have discussed the opportunities around free, and free trial access plans, but what about other pro bono approaches like not-for-profit, and educational or research plans, to help eliminate costs for consumers, and encouraging meaningful access.
Once we have establish the entry levels of access we can begin crafting additional levels of retail, partner, or internal levels of API access. It doesn't need to stop there, you can craft as many plans for API access as needed to meet the needs of every potential group, inside or outside of a company. API providers should work to be as transparent as possible with available plans, and what is available within each plan level, all the way up to partner tiers and potentially reseller or private label tiers of access.
Now That We Have A Better Understand Of What Goes Into Our APIs, How Do We Set Pricing?
Even though we know what went into an API, we don't always know how API consumers will perceive the value around an API, so we must be ready to adjust pricing based upon this perception. How we limit, and incentivize usage needs to reflect this value, and the relationship with each group of consumers. There should be paths that incentivize usage, encourage the purchase of resources in bulk, by the timeframe (monthly, quarterly), or maybe at specific times that benefit the provider, or the consumer. Remember, pricing is a two-way street, that can benefit the provider, as well as the consumer, but strike the balance that makes API platforms go round.
Let's Remember There Isn't Always Direct Value Generation From APIs
Something that often gets overlooked in API operations is the indirect value they can generate. APIs are a potential marketing vehicle when done right, pushing forward the exposure of a brand, driving web or mobile traffic, or generating valuable data and content through network and application activity. Many of these activities can be measured, just like with direct API consumption, but should be treated different than commercial consumption, and potentially act as marketing, advertising, and word of mouth around the value an API brings to the table.
Greasing The Wheels With Valued Partners
Public APIs have dominated the conversation for some time now, but web APIs bring just as much, or more value to trusted partners. APIs make it so I can quickly share the valuable resources I possess with those I feel would benefit most. While I try to make all of my APIs publicly available, it is my partners who get preferred access, and if I do it right, they can generate value via my APIs, and benefit what I am doing. If I do this the right way, I should be able to generate revenue from my APIs, while also sharing that exhaust with my trusted partners, and if they are the right kind of partners, they kick exhaust back my way as well.
Realizing The Value Of APIs Internally
As we've learned from the Steve Yegges rant about APIs at Amazon, and as the myth tell us, Bezos ordered everyone at Amazon to use APIs for the exchange of internal API resources. Amazon understood that APIs bring agility, and efficiency when done well, and can help internal groups work together, and like public API access, internal consumers can also have plans tailored specifically for their needs. This is where the true benefits of APIs are evident, and unfortunately is the aspect of APIs that is least discussed out in the open for everyone to learn from.
Units of Value Can Go Both Ways, Depending On Who Is Access An API
It is very common for APIs to charge for access, restricting access by some of the common units of value listed above. It is less common for APIs to pay consumers for access APIs, incentivizing the publishing of content, posting of images and videos, and other value generating ways of putting APIs to work. What is the value of the first image added to an API for a business location vs. the 10th photo added? What is the value of encouraging API consumers to add their own content to a a system, augmenting existing information. There are endless ways to encourage developers to contribute to a platform, the only limit is your own plan for defining the boundaries of this participation.
We Should Be Making Value Transferrable Across API Providers
All of this provides a standardized way for API providers to define the value of API resources, and incentivize usage, while also generating needed revenue. Money is spent accessing some resources, while money is generated for publishing or refining other resources. This two way value generation shouldn't be locked up within each API providers silo, and be transferrable between API providers. In 2015, developers are using not just one or two APIs, they putting many different APIs to work, and while API providers need to cover costs, and generate revenue, so do API consumers. It is two sides of the same coin--the API balance.
How Do We Compare The Value Of Value Across API Platforms?
The first challenge we will face is transferring this value from one silo to another. Even when platforms have comparable API resources available, rarely will it be an apples to applies comparison. While this exercise gives us a better look into how resources can be defined, and have a price applied to their consumption across multiple plan levels, this is limited to discussion around each individual platform. Before we can compare the value across API platforms, we need to standardize the business model for each API, and establish a ranking system for each provider, that will act as a weight when comparing provider to provider, and across many providers within an industry.
This is just my way of exercising my views around the development of API business models. Next I will explore the concept of API rating in 2015 as I see it, and try to find the linkage to the unit price established as part of API management operations in this post. Everything I discussed above is not hypothetical. It is rooted in API infrastructure solutions provided by companies like 3Scale. To craft this story, I had my 3Scale administrative console open for my own APIs, and theoretically walked through some of the known approaches to API monetization.
Once I am done playing with my thoughts around rating APIs and the resources they provide, I think I'll revisit this post about plans, and craft a formal look at Amazon, Twilio, and other well known APIs, and help provide ready to go API business model blueprint that others can follow. While there is endless ways to experiment and play here, I think most of the API space is just looking for ready to go business models, that are proven and make sense, that they can plug into their operations.