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.

My Basic YAML For Starter API Plans

I started developing a machine readable format for describing the API plans and pricing for leading API providers a few years back. Eventually I’d like to see the format live alongside OpenAPI, Postman, and other machine readable API specifications within a single APIs.json index. I am looking to adequately describe the plans and pricing for APIs, which are often just as important as the technical details, in the same way we’ve describe the technical surface area of an API using OpenAPI for some years now. People love to tell me that I will never be able to do it, which only makes me want to do it more.

I’m revisiting my work as part of work I’m doing on a clients project, which I’m also using to push forward my API portal and management toolbox. The project I’m working on has two API plans:

1) Starter - The free level of access everyone gets when signing up for access to an API. 2) Verified - A verified level of pay as you go usage once you have credit card on file.

I’ve taken the common elements across these plans and described them in a YAML format which allows me to remix the elements into the two plans I currently have, while also allowing me to reuse them for possible future plans, helping keep my approach consistent.

I’m using the plan elements in this YAML file to generate the plans and pricing page for each API. Generating two separate plan boxes, with the details, and elements of each plan. I keep all the moving parts of each plan defined as separate fields and collections so that I can reuse in any new plans. I also make use of the individual elements in comparison charts, and other pricing and plan related resources through an APIs portal. The specification isn’t perfect, but it provides me a starting point for considering how I make my API plans and pricing machine readable, and indexed as part of the APIs.json for each of my projects.

Next, I am taking API plan templates and auto-generating plans using AWS API Gateway. I’m going to play around with recreating some of the common plans we see for leading API providers out there using an existing gateway solution. Similar to generating the technical surface area of an API using AWS API Gateway, I’m looking to generate the business surface area of each API using the API Gateway in the same way. Definitely still a lot of work ahead of me when it comes to polishing my API plan specification format, but I feel like it is pretty good start, and after publishing a version for leading API providers, as well as some of the custom projects I’m working on, I think it will be a little more ready for prime time.

• Details

Twitter Finally Begins To Monetize Their APIs

It has been a long time coming, but Twitter has finally started charging for premium access to their APIs. Until now, you could only access data via the free Twitter API with limitations, or pay to use Gnip at the enterprise level–nothing in between. I’ve long complained about how Twitter restricts access to our tweets, as well as the lack of transparency and honesty around their business model. I’ve complained so much about it, I eventually stopped writing about it, and I never thought I’d see the day where Twitter starts charging for access to their platform.

While I have concerns about Twitter further limiting access to our data by charging for API access, their initial release has some positive signs that give me hope that they are monetizing things in a sensible way. They seem to be focused on monetizing some of the key paint points around Twitter API consumption, like being able to get more access to historical data, offer more Tweets per request, higher rate limits, a counts endpoint that returns time-series counts of Tweets, more complex queries and metadata enrichments, such as expanded URLs and improved profile geo information. Twitter seems to be thinking about the primary pain we all experience at the lower rungs of Twitter access, and focusing on making the platform more scalable for companies of all shapes and sizes–which has been core to my complaints.

Twitter even provides a quote from a client which highlights what I’ve been complaining about for some time about the inequity in Twitter API access:

I wish these premium APIs were available during our first few years. As we grew, we quickly ran into data limitations that prevented expansion. Ultimately, we raised a round of funding in order to accelerate our growth with the enterprise APIs. With the premium APIs, we could have bootstrapped our business longer and scaled more efficiently. - Madeline Parra, CEO and Co-Founder, Twizoo (now part of Skyscanner) @TwizooSocial

This demonstrates for me how venture capital, and the way the belief systems around it railroad folks down a specific path, and is blind to those of us who do not choose the path of venture capital. Twitter’s new pricing page starts things off at $149.00 / month, after the current free public tier of access, and climbs up five tiers to $2,499.00 / month. Giving you more access with each access tier you climb. While not a perfect spacing of pricing tiers, something that sill might be difficult for some startups to climb, it is much better than what was there before, or should I say, what wasn’t there. At least you can scale your access now, in a sensible, above the board vertical way, and not horizontally with separate accounts. Incentivizing the more positive behavior Twitter should want to see via their API.

Twitter should have started doing this back in 2008 and 2009 to help throttle bad behavior on their platform. The platform would look very different today if there had been a level playing field in the API ecosystem, and developers weren’t forced to scale horizontally. API monetization and planning isn’t just about generating revenue to keep a platform up and running serving everyone. Sensible API monetization is about being aware of, and intimately understanding platform behavior and charging to restrict, shape, and incentivize the behavior you want to see on your platform. Twitter has missed out on a huge opportunity to truly understand the API community at this level, as well as generate much needed revenue over the years. Shutting out many good actors, incentivizing bad actors, and really only recognizing trusted partners, while being blind to everything else.

After a decade of complaining about Twitter’s practices in their ecosystem, and their clear lack of a business model around their API. I am happy to see movement in this area. While there is a HUGE amount of work ahead of them, I feel like monetization of the API ecosystem, and crafting of a sensible API plan framework is essential to the health and viability of the platform. It is how they will begin to get a hold on the automation that plagues the platform, and begin de-platforming the illness that has become synonymous with Twitter during the 2016 election, while also leveling the playing field for many of us bootstrapped startups who are trying to do interesting things with the Twitter API. I’ll keep an eye on the Twitter premium APIs, and see where things head, but for now I’m cautiously optimistic.

• Details

Additional Call Pricing Info Are The Pressure Relief Valves For API Plans

I’ve complained about unfair API pricing tiers several times over the last couple years, even declaring API access tiers irrelevant in a mult-API consumer world. Every time I write about this subject I get friends who push back on me that this is a requirement for them to generate revenue as a struggling startup. With no acknowledgement that their API consumers might also be struggling startups trying to scale consumption within these plans, only to reach a rung in the ladder they might not be able to actually reach. My goal in this storytelling isn’t to condemn API providers, but make them aware of what things look like from the other side, and that their argument essentially pulls up the ladder after they’ve gotten theirs–leaving the rest of us at the bottom.

My complaint isn’t with startups crafting pricing tiers, and trying to make their revenue projects more predictable. My complaint is when the plans are priced too far apart and I can’t afford to move from one plan to the next. More importantly, my complaint is when the tier I can’t moved from is rate limited with a cap on usage, and I can’t burst beyond my plans limits without scaling to the next access tier which I cannot afford to reach. I understand putting hard caps on public or free tier plans, but when you are squarely in a paid access tier, you shouldn’t be shut down when you reach the ceiling. Sure, I might pay a premium for each additional call, but I shouldn’t be shut down and forced to move to the next higher access tier–which might be out of my monthly price range. I just can’t go from $49.95 to $499.95 in monthly payments as a small business, sorry.

The key element that needs to be present for me, even in situations where I cannot afford to jump to the next tier, is the ability to go beyond my plans usage, with clear pricing regarding what I will pay. I may not be able to jump from $49.95 to $499.95 as monthly payments, but I might be able to burst, and absorb the costs as I need. If my plan is capped, and I cannot burst, and know what I will be charged for my usage (even if at a premium), it is a deal breaker for me. While I would prefer API providers do away with access tiers, and go with straight pay for what you use model (like Amazon), I accept the reality that API access plans help startups better predict and communicate their revenue. As long as they have this relief valve for each plan, allowing me to stay in my plan, but consume resources beyond what my tier allows.

Having relief valves for plans won’t hurt your revenue forecasting. I would argue it will actually help your revenue (not forecasting) with bursts in revenue that you wouldn’t see with just a capped plan approach. If you have trouble seeing API access in this way, I would argue that you are primarily an API provider, and building business exclusively focused on an exit. If you can empathize, I would say you are focused on delivering a set of services that people need, and you are probably an active consumer of other services, broadening your empathy spectrum beyond just a startup exit objectives. I honestly don’t want to mess with startups ability to generate revenue with this storytelling, I’m just trying to make the case for us startups on the API consumption side of the coin. Ok, I lied, I kind of do want to mess up the revenue strategy for startups who are exclusively focused on an exit, because when there isn’t a relief valve, you won’t find me signing up for one of your predictable plans in the first place.

• Details

API Monetization Framework As Introduced By AWS Marketplace

I am learning about the AWS Marketplace through the lens of selling your API there, adding a new dimension to my API monetization and API plan research. I’ve invested a significant amount of energy to try and standardize what I learn from studying the pricing and plans for the API operations of the leading API providers. As I do this work I regularly hear from folks who like to tell me how I’ll never be able to standardize and normalize this, and that it is too big of a challenge to distill down. I agree that things seem too big to tame at the current moment, but with API pioneers like AWS, who have been doing this stuff for a while, you can begin to see the future of how this stuff will play itself out.

Amazon set into motion a significant portion of how we think about monetizing our API resources. The pay for what you use model has been popularized by Amazon, and continue to dominate conversations around how we generate revenue around our valuable digital assets. AWS has some of the most sophisticated pricing structure around their API services, as well as very mature pricing calculators, and have created markets around their resources (ie. spot instances for compute). You can see these concepts playing out in the guidance they offer software developers in their AWS Marketplace Seller Guide, which helps sellers modify their SaaS products to sell them through AWS Marketplace using two models: 1) metering, or 2) contract. When you list or application in the AWS Marketplace you must choose between one of these models, but both involve thinking critically about your monetization strategy, which includes your hard costs, as well as where the value will lie with your customers–striking the balance necessary to operate a viable API business.

According to the AWS Marketplace Seller Guide, each SaaS application owner listing through AWS Marketplace has two options for listing and billing your software:

• You can use the AWS Marketplace Metering Service to bill customers for SaaS application use. AWS Marketplace Metering Service provides a consumption monetization model in which customers are charged only for the number of resources they use in your application. The consumption model is similar to that for most AWS services. Customers pay as they go.
• You can use the AWS Contract Service to bill customers in advance for the use of your software. AWS Marketplace Contract Service provides an entitlement monetization model in which customers pay in advance for a certain amount of usage of your software. For example, you might sell your customer a certain amount of storage per month for a year, or a certain amount of end-user licenses for some amount of time.

No matter which plan you choose to deliver your API resources within, you will have to have the nuts and bolts of your API operations defined as part of your overall API monetization strategy. Each plan you offer needs to be derived from the hard costs involved with operations, but reflect the needs of your consumers. AWS gives you a handful of common dimensions for thinking through which type of plan you go with, and quantifying how you will be monetizing your API solution, in these nine areas:

• Users – One AWS customer can represent an organization with many internal users. Your SaaS application can meter for the number of users signed in or provisioned at a given hour. This category is appropriate for software in which a customer’s users connect to the software directly (for example, with customer-relationship management or business intelligence reporting).
• Hosts – Any server, node, instance, endpoint, or other part of a computing system. This category is appropriate for software that monitors or scans many customer-owned instances (for example, with performance or security monitoring). Your application can meter for the number of hosts scanned or provisioned in a given hour.
• Data – Storage or information, measured in MB, GB, or TB. This category is appropriate for software that manages stored data or processes data in batches. Your application can meter for the amount of data processed in a given hour or how much data is stored in a given hour.
• Bandwidth – Your application can bill customers for an allocation of bandwidth that your application provides, measured in Mbps or Gbps. This category is appropriate for content distribution or network interfaces. Your application can meter for the amount of bandwidth provisioned for a given hour or the highest amount of bandwidth consumed in a given hour.
• Request – Your application can bill customers for the number of requests they make. This category is appropriate for query-based or API-based solutions. Your application can meter for the number of requests made in a given hour.
• Tiers – Your application can bill customers for a bundle of features or for providing a suite of dimensions below a certain threshold. This is sometimes referred to as a feature pack. For example, you can bundle multiple features into a single tier of service, such as up to 30 days of data retention, 100 GB of storage, and 50 users. Any usage below this threshold is assigned a lower price as the standard tier. Any usage above this threshold is charged a higher price as the professional tier. Tier is always represented as an amount of time within the tier. This category is appropriate for products with multiple dimensions or support components. Your application should meter for the current quantity of usage in the given tier. This could be a single metering record (1) for the currently selected tier or feature pack.
• Units – Whereas each of the above is designed to be specific, the dimension of Unit is intended to be generic to permit greater flexibility in how you price your software. For example, an IoT product which integrates with device sensors can interpret dimension “Units” as “sensors”. Your application can also use units to make multiple dimensions available in a single product. For example, you could price by data and by hosts using Units as your dimension. With dimensions, any software product priced through the use of the Metering Service must specify either a single dimension or define up to eight dimensions, each with their own price.

These dimensions reflect the majority of software services being sold out there today. Make sure you not get stuck thinking about one way of thinking, like just paying per API call. Think about how your different API plans might have one or more dimensions, beyond any single use case.

• Single Dimension - This is the simplest pricing option. Customers pay a single price per resource unit per hour, regardless of size or volume (for example, $0.014 per user per hour, or $0.070 per host per hour).
• Multiple Dimensions – Use this pricing option for resources that vary by size or capacity. For example, for host monitoring, a different price could be set depending on the size of the host. Or, for user-based pricing, a different price could be set based on the type of user (admin, power user, and read-only user). Your service can be priced on up to eight dimensions. If you are using tier-based pricing, you should use one dimension for each tier.

Alll of these dimensions reflect the common building blocks of API plans and pricing which I’ve been tracking on for a number of years. It’s based upon Amazon selling their own APIs, as well as watching their customers price and sell their resources. Their pricing guide goes well beyond just APIs, and consider how you can generate revenue from any type of SaaS, but the dimensions they provide a place to start for ALL API providers, whether you are looking to sell them in the AWS Marketplace or not. You can find even more dimensions on my API plan research, but what Amazon provides will work for about 75% of the use cases out there today, and I’m looking to get you thinking critically your API monetization and plans, not provide you with too many options.

There just aren’t too many examples like this available, when it comes to thinking through how to price your APIs. My friends over at Algorithmia have pushed the conversation forward some with their algorithmic API marketplace, but you just don’t see this level of maturity with the pricing of resources over at Azure, Google, or others yet. Amazon is the furthest along in this journey. They have the most experience, and the most data regarding what digital resources are worth, and how you can measure and meter access. I think it will take a number of years to mature, but I think by 2020 we will see more standardization in how we structure the pricing for the most common digital resources available online–even if it is just the APIs we are selling on Amazon.

There will always be an infinite number of ways to charge for your APIs, but for many of the digital commodities that have become staples, we’ll see one or two common approaches stick. We’ll see less innovation in how we price the most used APIs, because those with market share will dictate the model that gets adopted, and others will emulate just so they can get a piece of the pie. As other API resources continue to mature, becoming digital commodities, we’ll see their pricing structure stabilize, and standardize to fit into market frameworks like we see emerging on the AWS platform. It will take time, but we’ll begin to see machine readable templates governing API pricing and plans, allowing cross platform markets to flourish, as API consumers figure out they can make API usage more predictable, budget-able, and orchestrate-able. We aren’t there yet, but you can see hints of this API economy over at AWS within their marketplace approach.

• Details

Selling Your AWS API Gateway Driven API Through The AWS Marketplace

I am getting intimate with AWS API Gateway. Learning about what it does, and what it doesn’t do. The gateway brings a number of essential API management elements to the table, like issuing keys, establishing plans, and enforcing rate limits. However, it also lacks many of the other active elements of API management like billing for usage, which is an important aspect of managing API consumption for API providers. With AWS, things tend to work like legos, meaning many of their services work together to deliver a larger picture, and I’ve been learning more about how AWS API Gateway works with the AWS Marketplace to deliver some of the business of API features I’m looking for.

Here is the blurb from the AWS API Gateway documentation regarding how you can setup AWS API Gateway to work with AWS Marketplace, making your API available for sale as a SaaS service:

After you build, test, and deploy your API, you can package it in an API Gateway usage plan and sell the plan as a Software as a Service (SaaS) product through AWS Marketplace. API buyers subscribing to your product offering are billed by AWS Marketplace based on the number of requests made to the usage plan.<br /
To sell your API on AWS Marketplace, you must set up the sales channel to integrate AWS Marketplace with API Gateway. Generally speaking, this involves listing your product on AWS Marketplace, setting up an IAM role with appropriate policies to allow API Gateway to send usage metrics to AWS Marketplace, associating an AWS Marketplace product with an API Gateway usage plan, and associating an AWS Marketplace buyer with an API Gateway API key. Details are discussed in the following sections.<br /
To enable your customers to buy your product on AWS Marketplace, you must register your developer portal (an external application) with AWS Marketplace. The developer portal must handle the subscription requests that are redirected from the AWS Marketplace console.

While it is not exactly the billing model I’m looking for in my API management layer currently, it provides a compelling look at selling your APIs in a marketplace setting. There are a growing number of APIs available in the AWS marketplace, but still less than a hundred from what I can tell. Smells like an opportunity for API providers to step up and publish their APIs. The linkage between AWS API Gateway usage plan and AWS Marketplace product makes a lot of sense when you think about having an APIs as a product focus for your organization. I will be writing more about this relationship in the future, as I think it reflects how we should be thinking about our API service composition, and how we craft our API usage plans.

I’m going to setup one of my simple, more utility style APIs, like screen capture, or proper noun search, and deploy using AWS API Gateway, then publish as an AWS Marketplace product. I want to have a clear view of what it takes, and what the on-boarding process looks like for a consumer. Another thing I’m interested in doing, is how can I also offer a more wholesale version of these APIs. Meaning, I’m not metering their usage with AWS API Gateway and billing via AWS Marketplace. It will be a separate product that gets deployed in their AWS infrastructure as an EC2, RDS, and maybe AWS API Gateway, where they aren’t billed by usage, and billed by the implementation. This is a model I’ve been watching, considering, and thinking about for some time, but only now getting to where the public cloud infrastructure is able to support this type of API deployment and management. It will be interesting to see what I can make work.

• Details

API Developer Account Usage Basics

I’m helping some clients think through their approach to API management. These projects have different needs, as well as different resources available to them, so I’m looking to distill things down to the essential components needed to get the job done. I spent some time thinking through the developer account basics, and now I want to break down the aspects of API consumption and usage around these APIs and developer accounts. I want to to think about the moving parts of how we measure, quantify, communicate, and invoice as part of the API management process.

Having A Plan We have developers signed up, with API keys that they’ll be required to pass in with each API call they make. The next portion of API management I want to map out for my clients is the understanding and management of how API consumers are using resources. One important concept that I find many API providers, and would be API providers don’t fully grasp, is service composition. Something that requires the presence of a variety of access tiers, or API plans, which define the business contract we are making with each API providers. API plans usually have these basic elements:

• plan id - A unique id for the plan.
• plan name - A name for the plan.
• plan description - A description for the plan.
• plan limits - Details about limits of the plan.
• plan timeframe - The timeframe for limits applied.

There can be more than one plan, and each plan can provide different types of access to different APIs. There might be plans for new users versus verified ones, as well as possibly partners. The why and how of each plan will vary from API provider to provider, but their are all essential to managing API usage. Something that needs to be well defined, in place, with APIs and consumers organized into their respective tiers. Once this is done, we can begin thinking about the next layer, logging.

Everything Is Logged Each call made to the API contains API key which identify the consumer, who should always be operating within a specific plan. Each API call is being logged as part of the web server, and ideally the API management layer, providing timestamped entries for every drop of APIs consumed. These logs are used across API management operations, providing a history of all usage that will be evaluated on a per API, as well as per API consumer level. If a request and response isn’t available in the API logs, then it didn’t happen.

Quantifying API Usage Every log entry recorded will have the keys for a specific API consumer, as well as the path of the API they are consuming. When this usage is viewed through the lens of the API plan an API consumer is operating within, you have the ability to quantify usage, and place a value on overall consumption by any time frame. This is the primary objective of API management, quantifying who is accessing API resources, and how much they are consuming. This is how valuable API resources are being secured, and in many situations monetized, using simple web APIs.

API usage begins with quantifying what consumers have used, but then there are other dimensions that should be considered as well. For example, usage across API users for a single path, or group of paths. Also possibly usage across APIs and consumers within a particular plan. Then you can begin to look across time periods, regions, and other relevant information, providing a more complete picture of how APIs are being put to use. This awareness is why API providers are employing API management techniques, beyond what can be extracted from database logs, or just website or application analytics–providing a more wholesale view of how APIs are consumed.

Invoicing For Consumption Now that we have all API usage defined, and available through the lens of API plans, we have the option of invoicing for consumption. We know each call API consumers have made, and we have a rate specific for each API as part of the API plans each consumer is subscribed to. All we have to do is the math, and generate an invoice for the designated time period (ie. daily, weekly, monthly, quarterly). Invoicing doesn’t have to always be settled with cash, as consumption may be internally, with partners, and with a variety of public consumers. I’d also warn against thinking of consumption always costing the consumer, and sometimes it might be relevant to pay API some consumers for some of their usage–incentivizing a particular type of behavior that benefits a platform.

Measuring, quantifying, and accounting for API consumption is the primary reason companies, organizations, institutions, and government agencies are implementing API management layers. It is how Amazon generates revenue from their Amazon Web Services. It is how Stripe, Twilio, Sendgrid, and other rockstar API providers generate the revenue behind their operations. It is how government agencies are understanding how the public is putting valuable public resources to work. API management is something that is baked into cloud platforms, with a variety of service providers available as well, providing a wealth of solutions for API providers to choose from.

Next I will be looking at the API account and usage layers of API management from the view of API provider, as well as the API consumer via their developer area. Ideally, API management solutions are providing the dashboards needed for both sides of this equation, but in some of the projects I’m working on this isn’t available. There is no ready to go dashboard for API providers or consumers to look at when standing up an AWS API Gateway in front of an API, falling short when it comes to going the distance as an API management solution. You can define accounts, issue keys, establish plans and limit manage API consumption, but we need AWS CloudFront, and other services to deliver on API logging, authentication, and other common aspect of management–with API management dashboards being a custom thing when employing AWS for management. One consideration for why you might go with a more robust API management solution, beyond what an API gateway offers.

• Details

Why Does AWS Charge By Usage And Other APIs Still Use Plans?

Amazon Web Services recently updated their billing for EC2 instances to be by the second, which I really like, because I’ll fire up an instance and run for minutes, then shut things down. I’m just looking to process patent downloads, or other intensive workload projects. Beyond just EC2, the rest of Amazon’s platform is still very usage based. Meaning, you get charged for whatever you use, with unit pricing for each resource designed to compliment how it gets put to use. You get charged for the hard costs of compute, storage, and bandwidth, but you also see per message, job, entry, and other types of billing depending on the type of resource being delivered via API.

With this model for doing APIs, I’m wondering why so many API providers still have access plans and tiers. I’ve vented several times that I think service tiers are a legacy of a SaaS way of thinking and does not scale for API consumers. Maybe back when we used a handful of APIs, but the number of APIs I’m using is pushing 50 these days, and I can’t alway justify a monthly subscription to get what I need. I’m looking to just get access to valuable API resources, and get billed for whatever I use. If I don’t use anything for 6 months, I don’t get billed for anything. Also, I want to be able to run large jobs which consume intense amounts of resources without hitting tier and other limits–just charge me for what I use. If I have a $1,000.00 to spend today, let me spend it. Don’t make me jump through hoops.

I know the answer to my question regarding why so many API startups do this. It is because the resources being provided via the API isn’t the product, us API consumers are. They are looking to ensure a certain level of headcount, monthly, and annual subscribers, so that they can sell us to their investors, and ultimately whoever purchases us like cattle in the end. I’m sure there are other reasons for having pricing tiers, but this is still the primary reason we see SaaS based pricing continue to be so pervasive in an API driven world. For me, if an API provider has tiered pricing, I’ll almost always go look elsewhere. I just can’t manage 40 or 50 subscriptions, and if the number of APIs keep growing, I can’t handle 100-200 subscriptions. I just need to pay for the resources my business needs, and nothing more. I sure don’t have time to be a product in your startup cattle auction.

Pay as you go, usage based pricing is one way the cloud giants will suffocate out the small startups in the future. While startups are trying to court investors, and their acquirers, the cloud giants will just offer a competing service, drop the price to run competitors off, then once the coast is clear, raise prices back up to an profitable state. To compete, more API providers will have to go with a utility based pricing strategy, while also offering wholesale versions of their APIs in the marketplaces for AWS, Azure, and Google. I can’t help think that things might have been different if the scales didn’t tip so hard towards all of us API consumers being the product, and API providers focused more on running businesses, and catering to our real world business needs. Oh well, we got the world we have, I’ll just keep plowing forward.

• Details

The Concept Of API Management Has Expanded So Much the Concept Should Be Retired

API management was the first area of my research I started tracking on in 2010, and has been the seed for the 85+ areas of the API lifecycle I’m tracking on in 2017. It was a necessary vehicle for the API sector to move more mainstream, but in 2017 I’m feeling the concept is just too large, and the business of APIs has evolved enough that we should be focusing in on each aspect of API management on its own, and retire the concept entirely. I feel like at this point it will continue to confuse, and be abused, and that we can get more precise in what we are trying to accomplish, and better serve our customers along the way.

The main concepts of API management at play have historically been about authentication, service composition, logging, analytics, and billing. There are plenty of other elements that have often been lumped in there like portal, documentation, support, and other aspects, but securing, tracking, and generating revenue from a variety of APIs, and consumers has been center stage. I’d say that some of the positive aspects of the maturing and evolution of API manage include more of a focus on authentication, as well as the awareness introduced by logging and analytics. I’d say some areas that worry me is that security discussions often stop with API management, and we don’t seem to be having evolved conversations around service conversation, billing, and monetization of our API resources. You rarely see these things discussed when we talk about GraphQL, gRPC, evented architecture, data streaming, and other hot topics in the API sector.

I feel like the technology of APIs conversations have outpaced the business of APIs conversations as API management matured and moved forward. Advancements in logging, analytics, and reporting have definitely advanced, but understanding the value generated by providing different services to different consumers, seeing the cost associated with operations, and the value generated, then charging or even paying consumers involved in that value generation in real-time, seems to be being lost. We are getting better and the tech of making our digital bits more accessible, and moving them around, but we seemed to be losing the thread about quantifying the value, and associating revenue with it in real-time. I see this aspect of API management still occurring, I’m just not seeing the conversations around it move forward as fast as the other areas of API management.

API monetization and plans are two separate area of my research, and are something I’ll keep talking about. Alongside authentication, logging, analysis, and security. I think the reason we don’t hear more stories about API service composition and monetization is that a) companies see this as their secret sauce, and b) there aren’t service providers delivering in these areas exclusively, adding to the conversation. How to rate limit, craft API plans, set pricing at the service and tier levels are some of the most common questions I get. Partly because there isn’t enough conversation and resources to help people navigate, but also because there is insecurity, and skewed views of intellectual property and secret sauce. People in the API sector suck at sharing anything they view is their secret sauce, and with no service providers dedicated to API monetization, nobody is pumping the story machine (beyond me).

I’m feeling like I might be winding down my focus on API management, and focus in on the specific aspects of API management. I’ve been working on my API management guide over the summer, but I’m thinking I’ll abandon it. I might just focus on the specific aspects of conducting API management. IDK. Maybe I’ll still provide a 100K view for people, while introducing separate, much deeper looks at the elements that make up API management. I still have to worry about onboarding the folks who haven’t been around in the sector for the last ten years, and help them learn everything we all have learned along the way. I’m just feeling like the concept is a little dated, and is something that can start working against us in some of the conversations we are having about our API operations, where some important elements like security, and monetization can fall through the cracks.

• Details

Decoupling The Business Of My Human Services Microservice

I’ve been looking at my human services API work through a microservices lens, triggered by the deployment of a reduced functionality version of the human services implementation I was working on this week. I’m thinking a lot about the technical side of decoupling services using APIs, but I want to also take a moment and think about the business side of decomposing services, while also making sure they are deployed in a way that meets both the provider and consumer side of the business equation. My human services microservice implementation is in the public service, which is a space where the business conversation often seems to disappear behind closed doors, but in reality needs to be front and center with each investment (commit) made into any service.

Let’s take a moment to look at the monetization strategy and operational plan for my human service microservice. Yes, a public data microservice should have a monetization strategy and plan for operating and remaining sustainable. The goals for this type of microservice will be radically different than it would be for a commercial microservice, but it should have one all the same.

• Monetization - How am I evaluating the investment into this project alongside any value that is generated, which I can potentially capture or exchange some value for some money to keep going.
  • Acquisition - What did it take for me to acquire the data and skills necessary to make the deployment possible.
  • Development - What time was invested in setting up the platform, developing the schema, data, definitions, code, and visual elements.
  • Operations - What does it take to operate the service? Maintain it, answer questions, provide support, and other realities of providing an online service today.
  • Direct Value - What are the direct benefits of having this service available to people looking for human services, or organizations looking to provide human services.
  • Indirect Value - What are the indirect benefits of having this service available, like increased conversation around human services, or maybe traffic and awareness of the Open Referral organization.
  • Partners - What partnership opportunities are actively being sought out, or will be opened up by having this service available.
  • Reporting - What type of reporting is necessary to operate and monetize this service, from tracking page views to understanding who is integrated with the data, and consuming data via APIs, or possibly through continuous integration of the Github repository.
• Plan - What is my plan for making this service available to the public, partners, or maybe internally use across my own projects.
  • Elements - My human services location API is designed to be publicly available, forkable, and reusable by anyone.
  • Limits - There are no limits on how each human services microservice can be used, or forked and reused. Ideally, any implementation provides attribution, and acknowledges the source of framework or data, but there really are no rules.
  • Metrics - I am measuring unique page views on each page, including of the machine readable YAML, JSON, and other formats. I’m also tracking on stars, forks, and commits for each service.
  • Commercial - Providing a clear track for commercial vendors to understand that the project needs their support, and can be improved upon, and evolved through their underwriting and support.

I need to have a coherent snapshot of what I’ve invested into each of my service. I need to have a base plan for how I will be executing the business side of this service–even if it just making something available for free. There are two dimensions to this conversation: 1) My view as the creator of this service 2) The view of folks who fork and implement as a service. Both dimensions should have a monetization snapshot, and a plan for executing within this business snapshot. I need all of this decoupled from any other service I am offering, but ideally they all use a common set of reusable patterns, just like the technical aspects of my microservices effort.

Just like needing the compute, database, DNS, and other technical layers to be stable and scalable across my microservices, I need the costs associated with these elements predictable and affordable. I need to know what it costs to define, design, deploy, manage, and deprecate my services. I need to know the best path forward for making them public, keeping them private, and being honest with commercial partners about the value that is being generated, both directly and indirectly. I need a way to report my costs, and revenue across hundreds or thousands of these services. I need to be able to scale this both horizontally across many services, but also vertically for single services which get deployed over and over, reused and continuously integrate wherever they are needed using Github.

I’ll keep applying this model across my human services project. I’m thinking that I’m going to be developing a whole buffet of human service microservices that run a 100% on Github like this, but I am also playing around with other varietals that run on other popular cloud platforms as well. I’m not one to subscribe to any particular API dogma, I’m just looking to explore what is possible, and do all of it as cheaply as I possibly scan, growing the number of projects I’m able to tackle. Of course, none of this would be possible without my partners funding my work, and helping me connect the technical and business aspects of doing API Evangelist.

• Details

Slow Moving Ransomware As The New Business Model

I was reading about the difficulties the City of New York was having when it comes to migrating off of the Palantir platfom, while also reading about the latest cybersecurity drama involving ransomware. I’m spending a lot of time studying cybersecurity lately, partly because they involve APIs, but mostly because it is something that is impacting every aspect of our lives, including our democracy, education, and healthcare. One thing I notice on the cybersecurity stage, is that everything is a much more extreme, intense, representation of what is going on in the mainstream tech industry.

Ransomware is software that gets installed on your desktop or servers and locks up all your data until you pay the software developer (implementor) a ransom. Ransomware is just a much faster moving version of what many of us in the software industry call vendor lock-in. This is what you are seeing with Palantir, and the City of New York. What tech companies do is get you to install their software on your desktop or servers, or convince you to upload all your data into the cloud, and use their software. This is business 101 in the tech industry. You either develop cloud-based software, something that runs on-premise, or you are a mix of both. Ideally, your customers become dependent on you, and they keep paying your monthly, quarterly, or annual subscriptions (cough cough ransom).

Here is where the crafty API part of the scheme comes in. Software providers can also make APIs that allow your desktop and server to integrate with their cloud solutions, allowing for much deeper integration of data, content, and algorithms. The presence of APIs SHOULD also mean that you can more easily get your data, content, and algorithms back, or have kept in sync the whole time, so that when you are ready to move on, you don’t have a problem getting your data and content back. The problem is, that APIs “CAN” enable this, but in many situations providers do not actually give you complete access to your data, content, or algorithms via API, and enable the true data portability and sync features you need to continue doing business without them.

This is vendor lock-in. It is a much friendlier, slower moving version of ransomware. As a software vendor you want your software to be baked in to a customers operations so they are dependent on you. How aggressively you pursue this, and how much you limit data portability, and interoperability, dictates whether you are just doing business as usual, or engaging in vendor lock-in. One thing I’m hopeful for in all of this, are the vendors who see transparency, observability, interoperability, and portability of not just the technical, but also the business and politics of delivering technology as a legitimate competitive advantage. This means that they will always be able to out maneuver, and stay ahead of software vendors who practice vendor lock-in and ransomware, whether of the slow or fast moving variety.

• Details

Temporary Interaction Limits

I spend a lot of time thinking about API rate limits. How they can hurt API providers, or as my friend Tyler Singletary (@harmophone) says incentivize creativity. I think your view on rate limits will vary depending on which side of the limit you stand, as well as your own creative potential and limitations. I agree with Tyler that they can incentivize creativity, but it doesn’t mean that all limitations imposed will ultimately be good, or all creativity will be good.

I found myself contemplating Github’s recent introduction of temporary interaction limits which means “maintainers can temporarily limit who can comment, create pull requests, and open issues among existing users, collaborators, and prior contributors.” While this isn’t directly about API rate limiting, it does overlap, and provide us with some thoughts we can apply to our world of API consumption, and how we sensibly moderate the access to the digital resources we are making available online.

When it comes to real-time fetishism around the digital world those with the loudest bullhorn often get heard and think real-time is good, while I am becoming less convinced that anything gets done in a 24-hour time frame. Despite what many want you to believe, real-time does not always mean good. Sometimes it might do you some good to chill out for 24 hours before you continue commenting, posting, or increase your consumption of a digital resource, whether you want to admit it or not.

Our digital overlords have convinced us that more is better and real time is always ideal. Temporary interaction limits may not be the right answer in all situations, but it does give us another example of rate limiting by a major provider that we can consider and follow when it comes to crafting limitations around our digital resources. This is what rate limitations are all about for me, thoughtful consideration about how much of a good thing you will need each second, minute, day, week, or month. It is a great way to turn a quality digital resource into something better or possibly maintain the quality and value of a seemingly infinite resource by imposing just a handful of limitations.

• Details

Key Factors Determining Who Succeeds In The API and ML Marketplace Game

I was having a discussion with an investor today about the potential of algorithmic-centered API marketplaces. I’m not talking about API marketplaces like Mashape, I’m more talking about ML API marketplaces like Algorithmia. This conversation spans multiple areas of my API lifecycle research, so I wanted to explore my thoughts on the subject some more.

I really do not get excited about API marketplaces when you think just about API discovery–how do I find an API? We need solutions in this area, but I feel good implementations will immediately move from useful to commodity, with companies like Amazon already pushing this towards a reality.

There are a handful of key factors for determining who ultimately wins the API Machine Learning (ML) marketplace game:

• Always Modular - Everything has to be decoupled and deliver micro value. Vendors will be tempted to build in dependency and emphasize relationships and partnerships, but the smaller and more modular will always win out.
• Easy Multi-Cloud - Whatever is available in a marketplace has to be available on all major platforms. Even if the marketplace is AWS, each unit of compute has to be transferrable to Google or Azure cloud without ANY friction.
• Enterprise Ready - The biggest failure of API marketplaces has always been being public. On-premise and private cloud API ML marketplaces will always be more successful that their public counterparts. The marketplace that caters to the enterprise will do well.
• Financial Engine - The key to markets are their financial engines. This is one area AWS is way ahead of the game, with their approach to monetizing digital bits, and their sophisticated market creating pricing calculators for estimating and predicting costs gives them a significant advantage. Whichever marketplaces allows for innovation at the financial engine level will win.
• Definition Driven - Marketplaces of the future will have to be definition driven. Everything has to have a YAML or JSON definition, from the API interface, and schema defining inputs and outputs, to the pricing, licensing, TOS, and SLA. The technology, business, and politics of the marketplace needs to be defined in a machine-readable way that can be measured, exchanged, and syndicated as needed.

Google has inroads into this realm with their GSuite Marketplace, and Play Marketplaces, but it feels more fragmented than Azure and AWS approaches. None of them are as far along as Algorithmia when it comes to specifically ML focused APIs. In coming months I will invest more time into mapping out what is available via marketplaces, trying to better understand their contents–whether application, SaaS, and data, content, or algorithmic API.

I feel like many marketplace conversations often get lost in the discovery layer. In my opinion, there are many other contributing factors beyond just finding things. I talked about the retail and wholesale economics of Algorithmia’s approach back in January, and I continue to think the economic engine will be one of the biggest factors in any API ML marketplace success–how it allows marketplace vendors to understand, experiment, and scale the revenue part of things without giving up to big of a slice of the pie.

Beyond revenue, the modularity and portability will be equally important as the financial engine, providing vital relief valves for some of the classic silo and walled garden effects we’ve seen the impact the success of previous marketplace efforts. I’ll keep studying the approach of smaller providers like Algorithmia, as well as those of the cloud giants, and see where all of this goes. It is natural to default to AWS lead when it comes to the cloud, but I’m continually impressed with what I’m seeing out of Azure, as well as feel that Google has a significant advantage when it comes to TensorFlow, as well as their overall public API experience–we will see.

• Details

Pricing Tiers Works For SaaS But Not Really For APIs

I get why SaaS, and API providers offer a handful of pricing plans and tiers for their platforms, but it isn't something I personally care for as an API consumer. I've studied thousands of plans and pricing for API providers, and have to regularly navigate 50+ plans for my own API operations, and I just prefer having access to a wide range of API resources, across many different companies, with a variety of usage limitations and pricing based upon each individual resources. I really am getting tired of having to choose between bronze, gold, or platinum, and often getting priced out completely because I can scale to the next tier as a user.

I understand that companies like putting users into buckets, something that makes revenue predictable from month to month, or year to year, but as we consumer more APIs from many different providers, it would help reduce the complexity for us API consumers if you flattened the landscape. I really don't want to have to learn the difference between each of my provider's tiers. I just want access to THAT resource via an API, at a fair price--something that scales infinitely if at all possible (I want it all). Ultimately, I do not feel like API plans and tiers will scale to API economy levels. I think as API providers, we are still being pretty self-centered, and thinking about pricing as we see it, and we need to open up and think about how our API consumers will view us in a growing landscape of service providers--otherwise, someone else will.

As I pick up my earlier API pricing work, which has two distinct components: 1) all API resources and pricing available for a platform 2) the details of plans and tiers which a complex list of resources, features, and pricing fit into. It would be much easier to just track resources, the features they have, and the unit price available for each API. Then we could let volume, time-based agreements, and other aspects of the API contract help us quantify the business of APIs, without limiting things to just a handful of API contract plans and tiers, expanding the ways we can do business using APIs.

As an API provider, I get that a SaaS model has worked well to quantify predictable revenue in a way that makes sense to consumers, but after a decade or more, as we move into a more serverless, microservices, devops world, it seems like we should be thinking in a more modular way when it comes to the business of our APIs. I'm sure all you bean counters can get out of your comfort zone for a bit, and change up how you quantify access to your API resources, following the lead of API pioneers like Amazon, and just provide a master list of API, CLI, and console resources available for a competitive price.

• Details

Dreaming Of A More Modular Event Driven API Monetization

I was learning about the approach Amazon has taken with their serverless API developer portal, and highlighting their approach to API plans, and couldn't help but think there was more to it all than just rate limiting your API. Amazon's approach to API plans is in alignment with other API management providers, allowing you to deploy your APIs, meter, rate limit, and charge for access to your API--standard business of APIs stuff.

Controlling access to a variety of API resources is something that has been well-defined over the last decade by API management providers like 3Scale, and now Tyk and DreamFactory. They provide you with all the tools you need to define access to APIs, and meter access based upon a wide variety of parameters. While I haven't seen the type of growth I expected to see in this area, we have seen a significant amount of growth because API management providers are helping to standardize things--something that will grow significantly because of availability from cloud providers like AWS, Microsoft, and Google.

We have a lot of work ahead of us, standardizing how we charge for API consumption at scale. We have even more work ahead of us to realize that we can turn all of this on its head, and start paying for API consumption at scale. I do not understand how we've gotten so hung up on the click and the view, when there are so many other richer, and more meaningful actions already occurring every second, of each day online. We should be identifying these opportunities, then paying and incentivizing developers to consume APIs in most valuable way possible. 

With modern approaches to API management, we already have the infrastructure in place. We need to just start thinking about our APIs differently. We also need to get better at leveraging POST, PUT, and PATCH, as well as GET, when it comes to paying for consumption. Imagine a sort of event driven API affiliate layer to the web, mobile, device, and even conversational interfaces--where developers get paid for making the most meaningful events occur. It makes the notion of paying per view or click seem really, really, shit simple.

Anyways, just a thought I needed to get out. The lack of innovation, and abundance of greed when it comes to API monetization and planning always leaves me depressed. I wish someone would move the needle forward with some sort of modular, event-driven API monetization framework--allowing some different dimensions to be added to the API economy.

• Details

A Machine Readable Definition For Your AWS API Plan

I was learning about the AWS Serverless Developer Portal, and found their API plan layer to be an interesting evolution in how we define the access tiers of our APIs. There were a couple different layers of AWS's approach to deploying APIs that I found interesting, including the AWS marketplace integration, but I wanted to stop for a moment and focus in on their API plan approach.

Using the AWS API Gateway you can establish a variety of API plans, with the underlying mechanics of that plan configurable via the AWS API Gateway user interface or the AWS API Gateway API. In the documentation for the AWS Serverless Developer Portal, they include a JSON snippet of the configuration of the plan for each API being deployed.

This reminds me that I needed to take another look at my API plan research, and take the plan configuration, rate limit, and other service composition API definitions I have, and aggregate their schema into a single snapshot. It has been a while since I worked on my machine-readable API plan definition, and there are now enough API management solutions with an API layer out there, I should be able to pull a wider sampling of the schema in play. I'm not in the business of defining what the definition should be, I am only looking to aggregate what others are doing.

I am happy to see more folks sharing machine-readable OpenAPI definitions describing the surface area of their APIs. As this work continues to grow we are going to have to also start sharing machine-readable definitions of the monetization, plan, and access layers of our API operations. After I identify the schema in play for some of the major API management providers I track on, I'm going to invest more work into my standard API plan definition to make the access levels of APIs more discoverable using APIs.json.

• Details

API Service Composition Baked Into The Cloud With Usage Plans For Amazon API Gateway

Being able to provide different levels of access for a single API has been one of the telltale characteristics of any modern web API. Savvy API providers know they don't just make their valuable API resources publicly available for anyone to use, they know you can craft a logical set of plans that are in alignment with your wider business objectives, outlining how any developer can put an API to use--this is the essential business of APIs.

Mashery was the first API management provider to standardize this approach to API access, something further evolved by 3Scale, Apigee, and others. Amazon's release of their API gateway wove API management into the fabric of what we call the cloud, and the introduction of usage plans, does the same for API service composition. Making the identification, metering, limiting, and monetization of resources made available via APIs, a default function of operations in the cloud.

Being able to take any digital asset, whether it is data, content, or an algorithmic resource, and make available via a URL, and control who has access, while also metering their usage, and charging different rates for this usage, is where the business of APIs rubber meets the road. API service composition lets you dial in exactly the right levels of access, and usage, required to fulfill a business contract, delivering precisely the service that customers are wanting for their web, mobile, and device apps.

It's taken a decade for this key element of doing business on the web to mature beyond just a handful of vendors, then into an assortment of open source solutions, and now something that is just baked into what we know as the cloud--allowing us to plan API access consistently and universally across all the digital resources we are increasingly storing and operating in the cloud.

• Details

Reconciling How Reliable APIs Are While Also Embracing Tone Set By VC Investment

I have done a lot of reading in the last week, catching up on my monitoring of the API space. I have read a couple of posts about the reliability of APIs, and the overall viability of building applications, and businesses based upon them. A couple of the posts were focusing on the shuttering of ThinkUp, but a couple others were just part of the regular flow of these stories that question whether we can depend on APIs or not--nothing new, as this is a regular staple of bloggers and the wider tech blogosphere.

My official stance on this line of thinking is that I would not want to be building a business, and application that depends on leading API platforms like Twitter, Facebook, Instagram, and others, but I will happily build a business, applications, and system integration on APIs. You see, this isn't an API issue, it is a business and vendor viability issue. As with other sectors, there are badly behaved business, and there are well-behaved businesses--I try to choose to do business with the well-behaved one's (can't always achieve this, but I try).

I find the ongoing desire of the startup culture to point out how unreliable APIs are, while simultaneously supporting the overall business tone set by venture capital investment, often delusionally blind levels of support, is just not reconcilable. I'm not saying all VC investment is bad, so don't even take this down that road. I am saying that the quest for VC investment, and the shift in priorities once VC investment is acquired, then further shift with each additional round, and the final exit is setting a tone that is completely at odds with API reliability. 

The problem really begins when APIs become the front-end for this blame. If I depend on vendors for my brick and mortar store, and the delivery trucks don't reliably bring my products, I don't talk about how you can't depend on trucks--I find new vendors. Of course, I can't find new vendors if they can't be replaced like Twitter and Facebook, but this is a whole other conversation, although it is also one that is a symptom of the tone being set by the VC currents (this is a business conversation). Blaming APIs instead of raising questions about the business ethics bar being set by venture capital shows the blinding power of greed, as the tech community refuses to blame VC $$, and shifts this to being about the viability of APIs, because I will get my VC $$ some day too bro!

I am not saying APIs are always good. I'm just saying they aren't bad. Hell, they aren't neutral. They are a simply a reflection of the business behind them, as well as being a reflection of the industry they operate in. Stop blaming them for businesses not giving a shit about developers, and the end-users. Maybe we could start changing the tone by admitting the #1 priority is always set by VC $$, and not by our API community, or even our end-users and customers, and all this shit is out of whack.

• Details

Pricing & Plans For 250 API Platforms

• Details

The Pricing & Plans For 250 API Platforms

I track on the API operations of around 2000 companies. Honestly, most of the 10K+ APIs in the ProgrammableWeb API directory have long been gone, deprecated, acquired, and had the lights shut off. There are only a couple thousand companies, institutions, organizations, and government who are doing public APIs, with only a couple hundred doing them in an interesting way.

This should not diminish the API conversation, as public APIs are just one aspect of the API discussion, and honestly it is one are that not all companies and organizations will have the stomach for. However, a certain amount of available public APIs will always play an important role in setting the tone for the entire API space, providing us with a (hopefully a diverse amount of) lead(s) when it comes to crafting our own strategies for operating our businesses on the Internet. Very little of what I do as the API Evangelist involves ideas that originate from my own head, and is something that requires a wealth of examples which I can point to in the wild. 

I am working on new ways to earn a living, while also generating research, analysis, code, and specification that the API sector can put to use in their own operations. One way I will be doing this, is by publishing technology, businesses, and politics of API design guides. This isn't API design as in the sense of REST, and how you craft endpoints, it is design thinking around the operations of your API. I learn a ton, flipping through the API portals of the 2000+ companies I keep an eye on, and I wanted to carve off small chunks of this, and share with you.

One area of API operations that has always fascinated me, and is one of the original founding focuses of API Evangelist, is how companies craft their API plans and pricing. Whether or not an API has a plans & pricing page is a very telling signal all by itself, as APIs are often a side-project, without any real support and investment from its parent company or organization, and the lack of a coherent plan, with simple pricing is often a sign of other deficiencies. However when an API plan and pricing page is present, I to find it to be a very telling representation of a company, organization, institution, government agencies, and even individual(s) in some cases. 

I track on many data points for any single API I keep an eye on. Ranging from their Twitter account, and Blog RSS, to the activity of their Github profiles. One of the areas I link to, when present, is the plans and pricing pages. This gives me the ability to quickly check up on the pricing of APIs across various business sectors, something that drives my API plans research. With the help of my organization API, and my screenshot API, I was able to easily harvest, organize, and make available the plans and pricing for 250 of what I feel are some of the more relevant APIs out there today.

To help make my research more explorable, I organized my API plan and pricing highlights into a single PDF guide, which allows you to experience the best of my API research, without all the clicking and searching I had to do. When I record details about the plans and pricing for an API, I have a rating of 1-3 for what I call API plan coupling, which is how tightly coupled their monetization strategy is to their API. Is the pricing that is present directly applied to API consumption, or is it more for the SaaS or PaaS side of things? While not all of the plans & pricing I include in this research are tightly coupled with the API, they are all from platforms where the API does play a significant role in platform operations. 

I have many of these the common building blocks employed for the API monetization strategy, and for the actual API plan implementations, recorded in a machine readable way, as part of my research. For this guide, I wanted to step back, and look at things through more of a design lens, and less from the technical, business, or even the political side of things. I think the visual of each plan and pricing page says a lot, and doesn't need a bunch of analysis from me to fluff it up. Just flipping through, you get a sense of what looks good, what doesn't, a process that I think will hopefully push forward more consistency across the API space.

There are numerous lessons present in the screenshots in this guide, around which building blocks are required to support API plans and pricing. Things like breaking things up into tiers, providing contact information, mechanisms for receiving a quote, demo, and know that a trial version is available. There are also lessons in how to present large amounts of very complex information, and some lessons in not how to do it, with plenty of evidence of why simple works. Oh, and that you should have a decent graphic designer! ;-)

I dismiss claims from the vocal startup, and VC elite, who point out the absolutes when it comes to API monetization, and pricing. That freemium won't work, and that offering unlimited access via API is always a mistake. Every company, API, and consumer will be different. In my opinion there are a wealth of strategies available out there to learn from, which we can apply in your own strategy. There are many variables, seen and unseen, that go into whether or not an API will be "successful" or not, and I strongly reject the notion there are absolutes -- there are only agendas, usually of the behind the scenes kind.

I have a number of API plans and pricing pages that I did not include in the current release of this guide. I will consider evolving, and shifting it up regularly, like I try to do with my other guides. I know I learn a lot from having them in a single place, that I can easily flip through and experience the design patterns present across these 250 API platforms, and hopefully you do to. I'm currently planning an interactive micro-app version of this research, as well as the coffee table edition for the API socialite who also enjoys entertaining.

You can purchase a copy of The Pricing & Plans for 250 API platforms over at Gumroad, get a copy of this design guide crafted from my API research, while also supporting what I do -- thank you!

• Details

Numerous Challenges When It Comes To Comparing Even Similar API Plans

I was pushing forward my API plan research this weekend, building on some of the tooling I developed during the last round, and the machine readable API plan format I hammered out late last year to help me define API plans. This time I'm applying it to nine of the SMS API providers I'm currently profiling, trying to get a new view of the plans of SMS APIs like Twilio and Plivo, but also working  to continue polishing my 100K view on the SMS API industry. 

Documenting The API Plans Of Nine SMS APIs
This last friday I got to work profiling the pricing, plans, rate limits, and access tiers for nine of the leading SMS API providers that I keep an eye on. From their pricing pages I gathered the common metrics, limitations, geographic considerations, pricing, and other element offered by each provider, putting them into separate buckets, standardizing how I record these valuable aspects of each API providers resource. This is a process I'd say 1/3 of the time falls right into place, 1/3 of the time it takes some translation and massaging to make it fit, and the other 1/3 things just don't fit into any common way of thinking.

Identifying The Common Metrics 
I found it pretty easy to identify the common metrics applied to SMS APIs, as most everything revolving around the concept of the message and a number. There are nuances to these resources that are being metered, like the separation between SMS and MMS, and a local phone number, toll free phone number, and a short codes, but for now I'm just trying to put pricing into common buckets, by loosely grouping the metrics that are applied via API plans.

List of Pricing Across SMS APIs
Along with identifying the common metrics being applied to SMS APIs, I was able to establish a list of the pricing that is being leveraged across these providers. I have machine readable entries for sending and receiving SMS or MMS, setup and rental fees associated with purchasing numbers, and short codes. I have ways of separating out fixed costs, such as fees, or per unit calls, as well as being able to handle ranges, and different rates and limitation being applied to different packages. It is far from perfect, but I am feeling pretty good about it as v1 of the API plan format.

Linking Plan Metrics To Resources
One big disconnect for me currently is being able to fully understand how metrics, limits, and pricing applies to API consumption, such as a linkage between a specific API plan element, and an individual API endpoint, and method. Another dimension of this is that most API plan elements represent a small portion of all the API endpoints available--meaning you only pay for sending message, procuring a short code number, and not for doing configuration, logging, and other more utility endpoints. I have a way to link each plan element to a specific path or verb, but I won't be implementing until I apply this to more API providers. I am not going to worry about this one right now, as I know it will happen in one of the next sprints for this work.

The Unclear World of Limitations
Another big gray area that I am not sure how I will deal with completely, is the murkiness of how rate limits that are applied. Only in some cases are limits actually broken down in detail, including where the ceilings are. Most of the time, the pricing is used as a governor for rate limits, meaning if you can afford it, there are no limits. For now, I will just state "unclear" if I don't know where the limits are, and most likely just leave as an individual transaction, as opposed to when labeling it as "range", or "unlimited", as I do in other cases. While I think API limits will come into focus as I profile more APIs, I also know this will continue to be a murky area for some providers, either because of a lack of vision when it comes business strategy, or in some cases provides will be trying to obfuscate the limitations so they don't scare consumers off.  

More API Plan Profiling Before I Iterate Further
There are many challenges present within as I work to compare these similar API plans, but as a first crack, I'm pretty stoked with what I have been able to accomplish, and make machine readable. In addition to including this data in the API listing for my API plan research, I also broke it out separately into a view that showcases the API plan details across all nine SMS API providers. I find it valuable to look at the plan elements alongside all of the API endpoints, but I also find it extremely valuable to see how the APIs plans size up against each other, without the technical details of the APIs distracting me--I like APIs, more than I like money. :-) 

Next. I'm going to move my research into some of the other more mature API stacks like email, compute, storage, and other essential building blocks for websites, mobile, and device based apps. Too establish the draft format for my API plans format, I looked at 60+ diverse APIs, but for this sprint i wanted to target a handful of APIs, present within common business verticals. Before I iterate on the API plan format any further, I want to make sure it works for defining the details of individual API plans, but also does it in a way that makes it easy to compare the plans for similar APIs, in a specific business vertical as well. This SMS research provided me with a first implementation of API plans applied across nine separate, but similar APIs, but it is also available as a machine readable index for the business of these APIs, within the APIs.json files for each API, as well as the APIs.json for the overall SMS API collection.

• Details

My Tooling And API For Gathering And Organizing The Details Of The Plans And Pricing For APIs

A couple of weeks ago I started playing with a machine readable way to describe the pricing, and plans available for an API. I spent a couple of days looking through over 50 APIs, and how they handled the pricing, and their API access plans, and gathered the details in a master list, which I am using for my master definition. I picked up this work, and moved it forward over the last two days, further solidifying the schema, as well as launching an API, and set of admin tools for me to use.

While my primary objective is to help me establish a machine readable definition that I can use to describe the plans of the APIs I provide, as well as the ones that I monitor as part of my regular work in the space--I needed an easier way to help me track the details of each API's plan. So I got to work creating an simple, yet robust admin tool that allows me to add one or many plans, for each API that I track on. 

To help me drive this administrative interface I needed an API (of course), that would allow me to add, edit, and delete the details for each plan, using my API plan schema as a guide. I got to work designing, developing, and launched the first beta version of my API plans API, to help me gather, and organize the details for any API I want, whether its mine, or one of the many public APIs I track on.

Now that I have an API, and an administrative interface, I'm going to get to work adding the data I gathered from my previous research. I have almost 60 APIs to enter, then I hope to be able to step back, and see the API plan data Ive gathered in a new light. Once I get to this stage, I'm looking to craft a simple embeddable page for viewing an API's plan, and create some visualizations for looking across, and comparing multiple APIs. I'm looking to apply this concept to verticals, like with business data via APIs like Crunchbase, AngelList, OpenCorporates, and others.

While my API plan schema is far from a stable version, it at least provides me with a beginning definition that I can use in my API profiling process. Here is the current version I have for the Algolia API, to demonstrate a little bit of what I am talking about.

This current version allows me to track the pages, timeframes, metrics, geo, limits, individual resources, extensions, and other elements that go into defining API plans, and then actually organizing them into plans, that pretty closely match to what I'm seeing from API providers. For each plan I define, I can add specific entries, that describe pricing structures, and other hard elements of API pricing, but then I can also track on other elements, giving me a looser way to track on aspects that impact API plans, but may not be pricing related.

I am pretty happy with what I have so far. Something I hope in a couple of years this could be used as a run-time engine for API operations, in a similar way that the OpenAPI Spec, and API Blueprint are being used used today, but rather than describing the technical surface area, this machine readable definition format will describe the business surface area of an API.

• Details

It Is All About No Limitations With The Enterprise API Plans

I am continuing to push forward my API plans research, where I look closely at the common building blocks of the service composition, pricing, and plans available for some of the leading API providers out there. I have no less than ten separate stories derived from Algolia, the search API provider's, pricing page--I will be using Algolia as a reference for how to plan your API, along with elder API pioneers like Amazon, and Twilio, for some time now.

On area of Algolia's approach I think is worth noting, is the enterprise level of their operations. They provide the most detail regarding what you get as part of the enterprise tier, being very public about their operations, in a way you just do not see with many API providers. When it comes down to it, the Algolia enterprise search plans are all about no limitations--I think their description says it well:

Your own dedicated infrastructure. Don't like limits? Meet our dedicated clusters. Optimal for high volumes of data, they scale to thousands of queries per second. Search performance and indexing times have never been so good.

The basic building blocks of how Algolia is monetizing their search API, records and operation API calls, melt away at the enterprise level. The lower four plans for Algolia API access meter the number of record, and operation API calls you make, and charge consumers, using four separate pricing levels. If you are an enterprise customer, the need for this metering melts away, eliminating the default limitations applied to lower levels of API consumption.

I support more transparency in enterprise API plans, as well as other partner tiers of access. I do not think Algolia's approach to delivering enterprise services is unique, but their straightforward, simple, and transparent approach to doing it is. In an API driven world, the enterprise levels of access do not always have to be that age old mating dance, that involves smoke and mirrors, and pricing pulled out of a magic hat--it can be just be about reducing the limitations around retail levels of API access, and getting business done.

• Details

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.

• Details

Playing With A JSON Representation For The Plans For Many Of The Leading APIs

I've long wanted a machine readable way to describe, discover, and compare the pricing of the leading APIs that I track on. I've slowly documented some of the common building blocks of how APIs are monetizing their APIs, as well as the details of the plans that go into platform operations.

As with all of my work, I am not looking to pull a machine readable representation out of thin air. I am taking the API definitions, and underlying schemas at play with pricing and planning APIs from AWS and Twilio, and identify other common patterns extracted from the approach of other API providers, from a diverse cross-section of the API sector, to bring this into focus.

To help me establish a common JSON schema that could possibly describe pricing and planning behind common API platforms, I took a look at 60+ providers, to capture a v1 schema:

I took a quick pass through these API platforms looking for signs of pricing, as well as other motivations behind the operations. I am now taking a second pass, and actually crafting a JSON representation of each platform, to help me push forward the schema, and better understand where it falls short--here are the first five that I have defined so far:

Alchemy API

Algolia API

Amazon EC2 API

Amazon S3 API

AngelList API

I have over 55 more providers to apply this schema to, before I am even willing to consider it an early start. Here is all of them in a single definition. I only have the plans described for the first five, but many of them do not even have plans, and various couplings with the monetization strategy of their core business. 

This is another aspect I should probably clarify. There is a value for each provider that rates the coupling of their API monetization strategy to their core business model. I am not sure what this means, and quickly expanded this to be a four level ranking, pushing beyond just three levels. Overall it seems to be helping me understand the motivations behind the API, in relation to the core business mission of the company or companies that make things go round.

You are welcome to look at all 60+ of the companies I'm looking at, I've published as a Github Gist below. I've already added four or five new ones, and will be pushing forward with more, as I have time. There is still much to flush out, and I still can't compare apples to applies like Amazon compute to Azure compute, or Twilio SMS to Tropo SMS, but I am able to discover APIs who don't have detailed plans, and which ones are only about content generation, or possibly selling products and devices.

I suspect, much like my other API definition work, this API planning specification will continue to evolve as I profile more companies. Hopefully eventually the spec, and the patterns I've defined from the approaches of API providers that are working, will become patterns that other providers can emulate, working to standardize what is possible when searching and ranking the pricing across hundreds or even thousands of API providers.

• Details

Customizable Terms of Service As Part Of Your API Plans

I am spending a significant amount of time looking through the pricing pages for leading API providers, working to get a sense for some of the common approaches to API monetization in use across the space. Along the way I am also finding some simple and unique approaches from API providers that I wanted to share as bit-size API planning stories here on the blog.

As I was working to understand the coupling between the Box SaaS business model, and the one applied to their API, I noticed an interesting element, that was part of their enterprise API plan--custom terms of service. At first glance it doesn't seem like much, but making elements of your TOS dynamic, allowing them up to be used as a metric within your API plans, opens up a whole world of possibilities. 

I have to note, this option is only available in the enterprise plan, which means only those with the most resources get this opportunity, but I still think its presence is meaningful. Right now, most terms of service and privacy policies are immovable shadows that guide how we do business and conduct our personal lives online, so the ability to think of them more dynamically, and one that could be tied to specific API access plans has huge potential. Unfortunately in the true Silicon Valley spirit, only some of this potential will be good, much of it will be in the name of exploitation, and the shifting of how power flows.

I have terms of service listed as a potential metric in my API plans research--we'll see where this goes, as my work evolves. I have a whole list of bit-size API monetization, pricing, and planning stories queued up. I will try to space them out, alongside other stories, but you will just have to suffer a little as I spend time expanding on my API monetization, and API plans research areas. 

• 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