I am revisiting the service composition for my own APIs on a regular basis lately, along with the ever increasing number of conversations I'm having with API providers about their own API monetization strategy. An example of this can be seen with the conversation I had with the Popup Archive about their monetization strategy for their AudioSear.ch API, and how they are shifting from a resource based perspective to a more experience based monetization approach. One side effect of this conversation, is that it looped me back around to thinking about the next steps for my own system.
I currently have 28 APIs, with almost 400 endpoints, most of which are content and data style APIs. This represents the core of the API Evangelist network, and now that I have it well defined as a single set of decoupled APIs, it is allowing me to move forward with a whole new generation of APIs. With my current set of content and data APIs, the number one consumer is me, any 3rd party usage is something I want to stimulate, and derive any revenue--my blog, curated, and other APIs are just value add to the traffic on my network of web sites.
With the next phase of my API development, I am looking to create more structured API resources that do things like convert CSV to JSON, process patent XML dumps to JSON, the indexing of websites, and much more. These newer APIs tend to go well beyond just pulling information from a database, and require a little more engineering, as well as potentially a lot more compute resources to make a reality. Historically I only meter my APIs to help me manage my costs, but moving forward I am looking to actually generate revenue as well.
The service composition I currently have defined using my 3Scale API infrastructure addresses the different types of consumers who potentially will be consuming my APIs. I have public, retail, trusted, partner, and platform service tiers that provide me with the buckets I need to manage my consumers. However, this doesn't address my granular level API monetization goals, something I am now adding as a credit based system on top of my existing 3Scale API service composition to address. Each of my APIs will now have a credit value associated with it, with many having 1 as the value, others could run you as much as 50 or 100 credits--I am guessing most will be in the 1-10 range.
I have an API-first system where I manage all my internal APIs, alongside all of the APIs I track on in the public sphere, and I am just adding this credit value to each entry, something that will then reflected in the APIs configuration file. As each API is called, it reports to my 3Scale API infrastructure what value of usage is being consume, and 3Scale does the rest for me. My API management infrastructure handles applying of the API usage to each users application, and which service composition tier that application operates within--and invoicing of each account accordingly.
It will take me a while to roll this out across my stack, and begin applying to some APIs that are in development and not quite ready for prime time. Hopefully my next update will have more examples of this in the wild. I'm eager to see how I can apply a credits cross my stack, better helping me understanding the value of each of the data, content, and algorithmic API resources I'm crafting, and ultimately whether this value translates to 3rd party API consumers.
