These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

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.

• Details

After Combining My API Plans, Pricing, And Rating Research I See Hints Of An API Industry Economic Engine

After writing I Have A Bunch Of API Resources, Now I Need A Plan, Or Potentially Several Plans, and How Are We Going To Create The Standard And Poors And Moodys For The API Economy, I wanted to combine what I had learned while crafting these stories, and try to look at how these two areas could work together. The API plan and pricing research is derived from existing approaches to API service composition introduced by providers like 3Scale, however the rating portion is fresh territory for me, with very few precedents to follow.

What I see when I start wading through a structured approach for API providers to craft meaningful API plans to serve up their API resources through, and how developers will be paying for API usage, via the apps they build, I begin to see the potential of a structured approach to API plans, and pricing. When you start thinking of the implications across providers, and consider the opportunities for developers to manage API consumption across API providers, and exchange the credits they purchased, or generated via API usage--a potential blueprint for an economic engine for the API space begins to emerge. 

I wanted to explore this concept, by crafting a visualization, and ponder how common approaches to API plans, and pricing, could be complimented by a standardized API industry rating system.

The only thing really original in this diagram, is the introduction of an API rating system, and the potential for developers being able to exchange credits between the API service providers they depend on. The rest of this standard API management approaches, that are defined by API providers like 3Scale. If you aren't familiar with modern approaches to API service composition, API providers can have many different API resources, as well as many different plans for subscribing to these API services, which provide a wealth of dimension for API providers to define, price, and limit how developers put API resources to use in applications.

The T Circle in the above diagram is where the current magic happens, when you put modern API management solutions to work for API operations. This allows you to mix and match access to your API resources, charging different prices, to different developer groups, introduce volume usage levels, and measure as many dimensions of consumption as you desire. Rarely do successful APIs have just one rate of access to them, this approach to API management allows providers to maximize access to resources, while also maximizing potential revenue around subscriptions, and usage consumption.

When you start putting API providers into standard API plans, and pricing framework like this, you start seeing intra-provider opportunities, industry wide benefits, as well as potential to really make API consumers lives much easier. If there were standardized ways to understand how API providers were pricing their resources, and how they tiered access, and adjusted pricing between these tiers, the API industry competition would heat up significantly. The problem comes in when you start allowing developers to transfer credits from provider to provider, while it may seem like you are transferring common units of value, but in many cases there are big differences between each API provider and what the value of one transaction may be.

Once you introduce an API rating system to the equation, it provides one possible way for rating each provider, and setting a benchmark that can be used to exchange credits between each platform. If each provider operated in a credit format, that could be cashed out using an exchange rate, or possible transferred from one platform to another, you'd start to see some potentially interesting market effects. I think you'd quickly see some negative, as well as positive effects, but I think some balance could be struck between some of the common API resources being served, and consumed across the API space. Newer resources, with fewer precedent would be very volatile for a period of time.

The R Circle in the above diagram is mean to reflect the potential of an industry wide API rating system, when you have standardized information on API pricing, across API providers. This pricing would vary across the plans each provider offers, but you could still come up with a median pricing for individual providers, and even entire industries. When you apply the rating system you could provide a potential exchange rate that could be applied when moving credits bought, and earned via each API platform, between API providers. Developers could explore which platforms allow them generate credits by engaging with API resources, exchange to other providers, where they could then spend the credits for other services they need, in lieu of cash. This also opens up the possibilities for markets for API credits exchanged across business sectors being impacted by APIs.

I'm just exploring concepts involved with common approaches to API plans and pricing, and brainstorming a potential API rating system, then using my imagination to understand the developer, and industry implications of this one possible future. Only one part of this equation exists, and it would take some significant work to bring such a thing into reality, but it is fun to explore, and consider one possible design for an economic engine, that could possibly scale, and drive the API industry.

• Details

Credit Based API Pricing, With Monthly And One-Time Plans

I'm reviewing the business models of many of the top API platforms over the last couple of weeks, and I’m seeing some pretty interesting approaches to API monetization. As I look through each API, I see that some platforms don’t have their API monetization strategy together at all, while others are following the pretty proven “cloud utility” model handed down from providers like AWS, and then I see some who are continuing to standardize how we pay for, and monetize APIs--which makes me happy.

One interesting pricing page I reviewed over the holidays, was from the file conversion API, ConvertAPI. They have a credit based API monetization approach, allowing you to buy a certain amount of credits on a monthly basis, or make one-time basis. Each area offers four tiers, allowing for the purchase of credits at a various rates. One thing I found curious though, is that your credits purchased monthly do not roll over, where your one time purchases do—I will have to think about the pros / cons of this more, before I comment.

The ConvertAPI also has a "credits cost table", providing an overview of how credits actually translate into actual API calls. Many file conversion APIs use a one-to-one rate for making API calls, while others cost 2, 3, or even 5 credits per each API call. I like this approach to defining API costs, and when your API developer account includes a API for monitoring account levels, it starts getting us closer to the API pricing standardization, and the automation we will need to continue the growth of the API economy.

I’m finding a lot of individual API monetization stories as I go through this latest round of research. I’m thinking I will have to spend a couple of weeks in February or March of 2015, step back and look at the monetization strategies of the 700+ companies I’m tracking on, and hopefully provide some better analysis of where we stand with this vital layer of the API industry. Along with the work I’m doing to encourage companies to create machine readable API definitions for their APIs, accompanied with machine readable licensing using API Commons, I want to help encourage the standardization of API pricing—then who knows, maybe someday API pricing can be machine readable, allowing us to make real-time decisions on the APIs we use based upon cost.

• Details

Salesforce Plans to Move Code Share to Github

Salesforce has a pretty cool Code Share area within the DeveloperForce ecosystem, which allows developers to share code snippets with the rest of the community.

Its a pretty cool way for anyone to share their techniques as code samples in a variety of languages, then letting the community vet the code, fork larger projects, and collaborate to improve the code for the greater good.

Acknowledging that they don't have the internal resources to fully support the process, Salesforce has halted code samples submission, announcing plans to migrate the Code Sharing program to Github.

Github is already the largest code sharing platform, providing social tools that developers are used to. Salesforce's publiclackowledgement that they don't have the internal resources to operate, the fact they identify the importance of such a program, and the decision to migrate to Github are all very savvy moves by the API pioneer.

Github is one of the most important platforms you can use to support your API. Using Github to host all your API code samples and SDKs, whether they are generated internally or by your developers community is becoming more than a novelty, but an essential part of API operations.

• Details

• << Prev
• Next >>

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.

Please contact me with any specific questions through any of these channels.

	Grab Me Via Email
	Grab Me Via Twitter
	Grab Me Via Github