{"API Evangelist"}

Initial Thoughts Around Monetization For An API Deployment Service

I am helping a client work through their monetization strategy for an API deployment service. To help me give me a starting point for the work, I wanted to take a look at a handful of existing service providers, that may not be a perfect match, but somewhat in the same realm--API deployment

For this phase of the work, I looked at six API deployment providers, who in my opinion have a pretty straightforward, modern approach to crafting, publishing, and sharing their pricing. It always amazes me how hard it can be to just find a companies pricing, let alone make sense of it...but I digress, that is another story.

Here are the API deployment providers I reviewed:

I think these six provide a good test sample to kick of my research. Most of the other API deployment providers didn't have a straightforward pricing model, were open source, or just didn't seem like a good fit.  As I looked through these companies approaches to monetization, I see two of the three hard costs of each provider covered:

The only one not present is "compute", but in my experience this is usually applied across the other pricing variables, as it is harder to calculate. After the hard costs, some of the obvious elements of API monetization are present:

These are the most common elements of API service provider pricing, providing tangible things that users will understand. There were also two additional elements I found, that I would consider less than common, but interesting enough to include:

The "connections "concept introduced by Restlet's APISpark platform is an interesting way to try and quantity the compute used by each API consumer. There were also three other I guess, kind of value-add aspects that were included in pricing packages:

I think the number of APIs, API calls, users, apps, and connections are all just ways for carving up the third hard cost of "compute"--with some profit built in of course. It all gives me a great framework to think about what is important when it comes to crafting a monetization strategy, like the hard costs of compute, storage, and bandwidth, but also provides the tangible elements that potential customers will likely understand, such as the number of APIs, API calls, users, and apps. 

Ultimately, I am a fan of simple, tiered API pricing, providing a free, $9.99, 19.99, $49.99, $99.99, and onward--kind of like with Restlet's APISpark. Each package should be assembled from all the moving parts identified, both hard costs, and perceived costs that the end-users will get  like storage, bandwidth, APIs, API cals, users, apps, etc. In my opinion, each tier should allow purchasing of additional units as needed, as well as being able to scale up and down the plan each month. 

Each of the providers listed above had a "contact us" or "enterprise" option for pricing. This is an area I'd like to see more transparency around what partnership opportunities there are, as well as potential reseller possibilities--I see no reason why some developers can't achieve credits for bringing in other business. I see the partner and reseller layer of any API, as the key to platform success, in a way that can also become a external marketing vehicle for the ecosystem.

Alrighty. That gives me a good amount of information to the prime the pump around the conversation with my client, as well as help build a foundation for how I can approach future API monetization strategy discussions. I will incorporate this into my api-pricing strategy, where i am trying to define a machine readable format that can be indexed as part of any APIs, APIs.json index. I am happy with this as a start, to what I see as a continuing conversation about not just strategies for API monetization, but also API service provider monetization.