Why I Labeled My Research API Plans Instead Of API Pricing

How to monetize APIs is on of the top questions I get from companies, right after concerns around security and control. I have separated my research into two main buckets, the first is focused on the questions I should be asking around API monetization as I'm planning my strategy, with the second focused on the actual plans for the operations of leading API providers. There is a lot of overlap between the two, but I guess API monetization is more strategy, and API plans is more about operations.

When I started my API monetization research, it was very focused on how do you make money from your APIs, resulting in the poorly crafted title. I'm not making the same mistake with my API plans research, which is meant to help define a wide range of motivations for providing APIs. I think every API should have an API monetization plan, to cover the costs of acquisition, deployment, and management in a sensible way, and all APIs should have a plan--not all APIs need to have pricing.

This is why I labeled my research into API plans the way I did, instead of just focusing on API pricing. Not all APIs have a straightforward API monetization strategy that can be translated into "pricing", from the dark side of platforms that are just content farms, to the brighter side where platforms are focused on the social good. There are many motivations behind API operations, this is why I'm trying to come up with some common ways to reference these motivations in a machine readable way.

Keep an eye on my API plan research, as I'm rapidly evolving the building blocks that go into planning your API operations. I am also publishing some common, machine readable definitions from leading API players like AWS, Twilio, and more. All of this is very alpha work, so it might seem cluttered at first, but I am working to slice it up into a 101, 201, and 301 series, as well as some sections that are dedicated to learning, with others more focused on strategy and then execution.

There is a lot of work left to be done before I can compare the pricing of cloud storage APIs like Amazon and Microsoft, or messaging like Twilio and Tropo, but in the short term, the ability to find APIs that depend on donations like Court Listener, and easily identify the data and content farms like Crunchbase and AngelList, who don't have real business models that API consumers can benefit from, is important to my operations.

Ultimately there are two primary motivations here--one, getting a machine readable way to discover and compare APIs and the resources they are providing. Second, I want to provide a way for API providers to easily understand the common patterns available across the API sector, and provide tooling they can use to craft the API plan that works best for them, based upon the successful plans already being put to work across the space.