This is my online domain where I work to understand the world of the Application Programming Interfaces, also known as APIs. This new way of sharing data using the web is touching almost every aspect of our increasingly digital lives, providing access to the bits and bytes that make our personal and professional worlds go round.

This is my research specifically into how API providers plan the business of API operations. This is the next step after my API monetization research, but is looking at the actual execution, which plans and access tiers are available, as well the other moving parts that go into generating revenue as part of API operations.

API Evangelist is a network of data driven projects and APIs which I curate and manage as part of this ongoing research, hoping to provide easy access to the moving parts of my work. Everything you see here runs on Github, making everything forkable, and reusable for both humans and machines.

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.

• Read The Blog

• Elements
  • Private - Is this plan a private one, available only to a limited audience? While the landing page, or overall portal might be publicly available, the API access itself requires approval, or existing account access before you can get more details. Private APIs are more common than public APIs, but you should think about the pros / cons of keeping things private.
  • Public - Is this a publicly available API operation, something that may only apply to some plans? While not all aspects of API operations will be 100% publicly available, there are some elements that anyone from the public can gain access to, even if it is rate limited in some way.
  • Free - Is this a free resource, or set of resources, something that may not apply to all plans. Free should be considered even if it is part of a trial, demo, or just a limited level of access by time other metric. Free should be a way to incentivize users to higher level of access, and not damage potential revenue.
  • Trial - Is there a trial period that is limited by number of days, which may not apply to all plans. Not all audiences will respond to trial levels of access, but may work will with incentivizing higher levels of access, and API consumption. Refrain from requiring credit cards for trial levels of access, as it deters signup from abuse by other providers.
  • Demo - This resource or set of resources has a demonstration associated with it, which might apply to multiple plans. Consider the possibilities of offer live, or scheduled demos with overall platform operations, as well as individual planned levels of acess.
  • Access - Access should not be taken for granted, requiring you to request access, or elevated access levels. While different levels of API access are common, it is also common to use API access itself as an element of planned API operations.
  • Setup - What are the costs associated with setting up and configuring an account for API access. Whatever time and resources are involved with setting up, or even perceived costs to end-users should be considered. Be careful making setup costs an obstacle for the on-boarding of consumers.
  • On-Demand - The resource or set of resources can be deployed, and shut down on demand. Each resource can be evaluated for how long it should be available. With current approaches to virtualizations, it is easier to make API resources available on demand, similar to how Amazon has done with many of their cloud compute resources.
  • Reserved - There are opportunities to reserve an instance of a resource or set of resources for specific time frames. If the resources are also available on-demand, a complimentary reserved option should also be considered as part of planning operations.
  • Volume - Volume pricing levels are available, with plans based entirely on volume level access to resources. Some platforms operate entirely on volume levels of API access, and levels should be crafted with end consumers in mind, and how they will be consumed, and at what levels.
  • Spot - There is an opportunity to big on resources in a localized or distributed marketplace driven environment. Maybe the demand for a resource changes from week, month, season or otherwise, and allowing for bidding can increase competition for a variety of API resources.
  • Dedicated - Resources can be allocated in a dedicated state, remaining available with no downtime, or according to SLA. This element is complimentary to on-demand, and reserved instances, where the resources can be purchased on a dedicated bases. For many API resources dedicated will be the default state, and not worth mentioning unless on-demand, and other elements are available.
  • Infrequent - Resources are accessed infrequently, treating them as warehoused, or off to the side. Another side of the resource availability which focuses on these infrequent levels of access, and may allow a users access or plan shift from infrequent, to higher levels, if rate limits are exceeded.
  • Archive - Resources are in an archived state and require very little access, and can be stored in different manner. Like infrequent, archive is mean for maybe one-time access, in future dates. Think of these levels as minimum rate limits, which base pricing not on volume, but only is cheap if minimum thresholds are met.
  • Subscription - There is a regular, recurring element to accessing a resource, as part of a larger subscription part of, or separated from plans. In addition to the regular usage, a subscription plan usually continues, and has costs associated with it even if there are no calls against the API made.
  • Personal - There is a personal element to a set of resources, meant for the casual user, and probably not developing an application or custom integration. These elements of API access usually involve some way for access APIs for non-developers through API reciprocity services like Zapier, or API aggregation providers like Cloud Elements, and not meant for developers.
  • Commercial - There is a commercial licensing element to a set of resources, which require additional business or legal requirements. This element may not be cost associated, and just stipulate there are commercial opportunities around an API. These elements may require requesting access, or additional steps before they can become available.
  • Non-Commercial - The platform allows for non-commercial access to resources, which usually means there is additional commercial requirements. Allowing non-profit organizations, researchers, and other potential API consumers the ability to validate their identity, and achieve reduced, or free levels of access can benefit the overall platform reach, and potential marketing engine.
  • Educational - A platform provides considerations for K-12 or higher educational access to resources. Like non-profit levels of access, education can benefit the overall platform reach, and benefit other marketing efforts. Reaching educational users, can lead to future individual, business, or institutional users, and improve the overall platform image.
  • Wholesale - There are wholesale options around deploying and accessing resources that are available via a platform. With cloud computing providers like AWS, Heroku, and Google, as well as virtualization technology like Docker, providing wholesale implementations of APIs are growing more possible, and are becoming more commonplace in API plans.
  • Government - A set of API resources is available specifically for government access, meeting the specialized needs of local or federal government use. Complimentary to non-profit, and educational elements of access, government considerations are growing more common place for some API providers to offer.
  • Internal - A set of resources are tailored specifically for internal consumption rather than for public or partner level access. Internal APIs, like public ones will usually have a portal available at an Internet URL, but will require additional access before you can see anything related to the API.
  • Partner - There is a focus on partner access to resources, resulting in separate access layers, and features dedicated to partner level consumption. While anyone accessing APIs can be considered a partner, these levels of access usually require much more vetting, making sure business objectives are in alignment, and legal obligations are met. Keeping partner access layers as transparent as possible helps keep harony with lower levels of public, or even internal API access.
  • Reseller - There are reseller opportunities in place around resources available via the platform, that allow approved API consumers to access resources, as well as resell access to resources. Resellers are paid a fixed amount, or possibly percentages of sales of products and services, which could include accessing and usage of API resources.
  • Venture - There are venture opportunities around a platform and the resources available, allow for investments to be made, or possibly received. API portals are often used as idea incubation area, but some API providers are going further and allowing for direct investment via the platform, opening up the opportunity financially supporting of various aspects of API operations, and products within its ecosystem
  • Type - Are there custom types of plans available, with a grouping dimension that goes beyond just the available plans. Thinking of plan types as a sort of categorization, allowing plans to be grouped by other dimensions, for more easily sharing with different groups. Think about separate between SaaS, developer, or possibly enterprise levels of access, and how plans can be organized by type.
  • Features - Additional features, usually key / value pairs that can be used to describe addition elements of API access and consumption. The purpose of this research is to identify some of the common elements of how API providers plan their operations, and there will be a long tale of features that I do not capture--these are features.
  • Marketing - Is a big part of API operations about driving marketing efforts for other aspects of business operations. Direct API access is not always the primary motivation for having an API, especially a public API. There are a number of ways to increase attention to products, services, as well as the overall corporate engine using APIs. Acknowledging this across API planning is important to understanding the value generated by API consumption, beyond direct elements.
  • Branding - Is there a strong brand aspect to API operations, with clear guidelines, resources, and a presence for the companies brand. It is common to require API consumers to provide brand attribution on their site, and sometimes on web or mobile applications, as part of the API consumption contract. Branding should be reflected as an element for all public APIs, with details about different requirements for different plan levels.
  • SaaS - Is the API operations secondary to a strong SaaS focus for a platform. How does an API add value to a SaaS offering? Considering the relationship between an API, and how it can benefit end-users of the platform is important to establishing a stable plan that can benefit both sides of the operation in harmony.
  • PaaS - Is the API operations secondary to a strong PaaS focus for a platform. How does an API add value to a PaaS offering? Considering the relationship between an API, and how it can benefit end-users of the platform is important to establishing a stable plan that can benefit both sides of the operation in harmony.
  • Traffic - Is a primary focus of an API platform centered around driving traffic to a web or mobile presence. If there is a solid business model around users accessing content or data, driving traffic through an API, without charging API consumers can be a successful approach. How can API consumers be incentivized to drive more traffic to web and mobile properties, by extending the reach of the platform through APIs.
  • Content - One of the primary objectives for API resources existing is in support of acquiring data and content that fuels platform operations. This is a very common element of successful API platforms that are operating today, such as Crunchbase or Angellist, or even Twitter and Tumblr. These are all examples of platforms where content acquisition is a core element of their API plans.
  • Devices - Situations where APIs are available in support of devices. You can see examples of this with Fitbit or Nest, where they API is just value-add to the devices, allowing 3rd parties to develop applications, and put content or data to use that is generated around the API. This is the layer of the API space that is expanding to what is often called Internet of Things (IoT).
  • Products - An API primarily exists to support the existence, or drive the sales of another product, or product line. I separate out devices from this grouping, because they require separate attention. This could describe entire supply chain integration using APIs, all the way to affiliate or reseller style systems like used by Amazon. There are a number of ways products can be sold, by putting APIs to work.
  • Services - API resources exist to support other related services, and act as value-add to the primary business focus. This is somewhat duplicate to SaaS or PaaS elements, but more likely is about the delivery of classic services like Uber, TaskRabbit, and other sharing economy solutions are focused on today. How is an API driving the demand of other services, that may not be software based, and bridge into the physical world.
  • Syndication - API resources exist to encourage syndication of data, content, and other digital resources. How are APIs supporting the syndication of data and content to other public or private locations, something that may overlap with embeddedable aspects of API operations. APIs driven syndication can be seen in popular platforms like Twitter or Facebook.
  • Analytics - A set of API resources exist to gather, refine, and organize data for the purpose of driving analytics. While these analytics might be also extended to API consumers, as well as end-users, one of the primary elements of API plans is to generate much needed data for use in analytics, increasing the value of a central, or even distribute resources.
  • Reporting - A set of API resources exist to gather, refine, and organize data for the purpose of driving reporting efforts. Analytics is the intelligence, and reports is the distribution model. Using APIs to drive static, or even dynamic reports that can be published, printed, or delivered via dashboards.
  • Talent - API resources are focused on driving talent acquisition, or even placement with ecosystem related companies or as part of wider services. This could be in support of an actual recruitment platform, or could just be one aspect of what an API platform does to support talent needed internally, by partners, or even end-users of recruitment related services.
  • Security - Access to API resources provide a security benefit, or are in support of other related security products and services. There should always be a base level of security to just keep a platform stable, but sometimes additional, or tighter security elements can be factored into the plan for overall platform operations. Security is an ever-increasing aspect of overall platform health and stability.
  • Terms of Service - API resources allow for the dynamic configuration of available terms of service that cover access and usage of resources. Terms of service will play a key role in defining every element of platforms, so it makes sense that it can be a variable used across API planning decisions, and even allow for it to be part of different levels of plans, allowing TOS to play variable roles, depending on which plan you exist in.
  • Governance - API resources are focused on governance related tasks within a company or possibly a wider industry. For APIs that operate in more heavily regulated spaces, governance will be a pretty big element of planning around APIs. Governance can be applied across API operations, and subject to variability depending on plan levels and partner tiers of access.
  • Donations - API resources allow for, or depend on donations as part of platform operations. Not all APIs will be operating for profit, and will require donations for all, or part of the operational budget. These donations might be large, or they might be smaller from individual API consumers, or possibly end-user groups that benefit from an APIs existence.
  • Grants - API resources exist because of grant related resources, which pay for their design, deployment or operations. Similar to donations, grants could be more formal funding opportunities for certain APIs that provide a civic or public good. Part of the goal in identifying this as a building block, is bringing more focus to the need of some APIs in this area, and drive more grant funding their way.
  • Advertising - API resources exist in support of advertising related elements of platform operations, driving advertising, or possibly alleviating the need for advertising to be present. The purpose of the APIs might be directly tied to advertising, or be more about helping drive traffic, or attention to resources that depend on advertising for their revenue. This element is focused on how advertising is coupled to API planning, no matter how tight it is.
  • API - There are APIs available to access all or part of the plans, pricing, or limitations around an API platform operations. The API platforms I track on that have been around the longest, and are the most mature, have APIs for consumers to use, that gives access to plan information, rate limits, pricing, and other aspects of API operations. I include this as essential, because it will be something every API provider will need to complete in the future.
  • Organization - There are organizational elements around API access and usage for API consumers to take advantage of. Are API plans organized by organization, or possibly specific access only for a specific group. How does user organizations, groups, and other ways to categorize API consumption applied at the API planning level?
  • Customization - There are customization opportunities around API plans, pricing, and rate limits, giving more control to consumers to customize their experience. For many plans, things may be fixed, but as you go further up the chain, into enterprise and partner level tiers, there may be opportunities for customization of plan elements, where other users do not have the opportunity.
• Extensions
  • Add-Ons - Factoring the availability of add-ons into specific API plans or overall API operations.
  • Connectors - Factoring the availability of 3rd party or internal platform connections into specific API plans or overall API operations.
• Geo
  • Overview - Providing an overview of what geographic regions are covered or available as part of API consumption.
  • Country - Providing API access or replication within specific countries.
  • Region - Providing API access or replication within specific regions.
  • On-Premise - Providing API deployment locally or within existing infrastructure, providing on-premise access levels.
  • Co-Location - Allowing for access of API resources via colocated facilities.
• Limits
  • Charts - Providing a chart with a listing of all endpoints and limits for each one.
  • Overview - A single page which provides an overview of limits that are in place on API operations.
  • Inline - Providing information about rate limits inline, either within documentation or available within API response details.
  • Range - Considering a range of values when measuring API consumption, and evaluating plan level access.
  • Resources - Limits are place upon specific endpoints or verbs, providing granular controls over API resources.
  • Increased - Opportunities for increasing rate limits either by changing plans, or simply requesting limits to be raised.
  • Unlimited - The ability to overcome limits, and achieve unlimited access to resources.
  • Service Level Agreement (SLA) - A service level agreement (SLA) is applied as part of API operations as a whole, or as part of particular plans.
  • API - There is an API specifically for accessing limitations around API resources for API consumers to use.
• Metrics
  • Access - Where access to an API is on the table, and might not be publicly available, or part of all plans. Differing from API access as an element, this is about actually limiting entire APIs from various groups and plans, and allowing it to be metered as part of overall measurements.
  • Calls - The most fundamental metric for APIs, the API call.
  • Value - What is the value of an API or endpoint, is it simple 1, or maybe 10, allowing for multiple value settings.
  • Transaction - Allow for the concept of transactions to exist which may span multiple API calls, moving a single concept forward.
  • Count - Tracking by the count of something, could be API calls, files, or any other county of objects that are part of API operations.
  • Instances - Allowing for instances of resources that are available via an API platform, and can be used in different ways within existing plans.
  • Matches - Allowing for the measurement of API access in terms of when pre-defined matches are returned, rather than all of the results.
  • Message - Charging per message rather than each API call that is required to prepare, send, or access messages.
  • Volume - Volume is used as a basic measurement of how consumers can access API, providing a standard set of pricing, as well as volume pricing.
  • Compute - Providing API resource access based upon various levels of compute power.
  • Load Balancing - Measurement of resource usage, based upon the amount of load balancing that occurs.
  • Operating System - Measurement of resources, based upon the operating system for compute resources.
  • Storage - Measuring API resources based upon the size on the disk.
  • Uploads - Restricting and measuring API access based upon the number of file uploads.
  • Upload Size - Restricting and measuring API access based upon file upload size.
  • Upload Speed - Restricting and measuring API access based upon file upload speed.
  • Records - Measuring API access based upon the number of records accessed or returned.
  • Containers - Measuring API access based upon the number of folders, buckets or virtual containers deployed.
  • Transcripts - Measuring API access based upon the transcripts generated.
  • Bandwidth - Measuring API access based upon the amount of bandwidth used.
  • Connections - Measuring API access based upon the number of connections or threads made to resources.
  • Simulations - Measuring API access based upon the number of simulations generated.
  • Transfers - Measuring API access based upon the number of transfers that are executed.
  • Transfer Limits - Using the ability to change transfer limits as a metric in API consumption.
  • Sync - Measurement for API consumption based upon the number of syncs that are exected.
  • Conversions - Measurement for API consumption based upon the number of conversions that are executed.
  • Syndication - Measurement for API consumption based upon how much syndication occurs.
  • Connectors - Measuring API access baed upon the number of connectors that are employed, or part of account access.
  • Relationships - Measuring API access baed upon the number of relationships between users and objects that are established or accessed.
  • Migrations - Measurement of API accessed based upon the number of migrations that occur.
  • Archives - Measurement of API accessed based upon the number of archives that are created.
  • Rollback - Measurement of API accessed based upon the number of rollbacks that are executed.
  • Tasks - Using the number of tasks that are started or completed as a measurement of API access.
  • Events - Measuring of API consumption based upon the number of events that occur or are triggered.
  • Trainings - Measurement based upon the number of trainings that occur around API access.
  • Maintenance - Measuring maintenance events that occur, and affecting API consumption based upon.
  • Latency - Measuring the latency that occurs as part of API access, and allowing it to impact API consumption plans.
  • Performance - Using performance as a consideration when measuring API consumption.
  • Users - Using the number of users as a metric when it comes to planning, and pricing adjustments.
  • Media - Measuring specifically media related considerations as part of API consumption tracking.
  • Scan - Measure the scanning of a physical or digital object involved in API operations.
  • Support - Directly using support elements as a consideration in API resource planning and consumption.
  • Fees - Fees that are used as part of API accounts, and consumption, and applied as part of API plans.
  • Percentages - The application of various percentages as part of measuring API consumption, and plan operation.
  • Consulting - Factoring in hourly consulting as part of API consumption, and plan operations.
  • Priority - Providing the option of being prioritized in API requests and responses, and measured as part of overall planning.
  • Groups - API access adjusted based upon grouping, or group level access which is aside from standard plans.
  • Zone - Another form of grouping API access, into zones, allowing consumers to access and use resources by zone.
  • Memory - Allowing for the measurement of resource access to be determined by the amount of memory available or consumed.
  • Health - Factoring in health checks in API consumption, and charging specifically on health checks, or changing plans based upon health results.
  • Encryption - Considering the existence of, or strength of encryption as part of the API consumption process.
  • Characters - Counting of textual characters as part of the overall API consumption tracking process.
  • Agent - Tracking on physical or virtual access to human agents as part of API consumption.
  • Price Per - Considering a price per a specific amount of API calls or other metric being applied as part of API consumption.
• Overview
  • Dedicated Plans / Pricing Page - Providing a single landing page, available at a simple URL, with all the information about plans available as part of platform operations. There may be more than one plan overview page available, for example one for SaaS side of offering, one for developers, and another possibly for enterprise or partner consumers.
• Resources
  • Endpoints - Providing access constraints based specifically on API endpoints allowing granular controls over each available resource.
  • Verbs - Allowing access controls applied down to the HTTP verb level, providing granular controls for GET, POST, PUT, DELETE, and other dimensions of resources.
• Timeframes
  • Seconds - Managing, guiding, and restricting plan entries in seconds. This is a common timeframe for considering rate limits, and judging the overall volume requirements of different users. Availability in seconds is often directly linked to compute resources being applied as part of operations, and tie in with overall availability.
  • Minutes - Managing, guiding, and restricting plan entries in minutes. Like seconds this is a common timeframe for considering rate limits, and judging the overall volume requirements of different users. Availability in seconds is often directly linked to compute resources being applied as part of operations, and tie in with overall availability.
  • Hourly - Managing, guiding, and restricting plan entries in hours. While there may be rate limits at the hourly level, this timeframe is more applied to resources that are on-demand and ephemeral, and can be consumed as needed, in a utility style that is becoming common way to plan API access.
  • Daily - Managing, guiding, and restricting plan entries in days. Like seconds and minutes this is a common timeframe for considering rate limits, and judging the overall volume requirements of different users. Availability in seconds is often directly linked to compute resources being applied as part of operations, and tie in with overall availability.
  • Weekly - Managing, guiding, and restricting plan entries in weeks. This timeframe is more used to organizing billing and support cycles, organizing resource usage and services rendered within the weekly time period, and aligning billing, and other aspects to this timeframe.
  • Monthly - Managing, guiding, and restricting plan entries in months. Like weekly, this timeframe is more used to organizing billing and support cycles, organizing resource usage and services rendered within the weekly time period, and aligning billing, and other aspects to this timeframe.
  • Quarterly - Managing, guiding, and restricting plan entries in quarters. Like monthly, and weekly, this timeframe is more used to organizing billing and support cycles, organizing resource usage and services rendered within the weekly time period, and aligning billing, and other aspects to this timeframe.
  • Annually - Managing, guiding, and restricting plan entries in years. Like quarterly, monthly, and weekly, this timeframe is more used to organizing billing and support cycles, organizing resource usage and services rendered within the weekly time period, and aligning billing, and other aspects to this timeframe.

These building blocks are constantly being added to and reorganized. If there is something you think should be here feel free to let me know. Remember that this represents my living research, and will evolve, expand and actually seed new research areas as I find the time to pay attention to API testing.

As I keep an eye on the space I curate news, bookmark organizations, watch interesting tools, and work to understand what deployment solutions are being applied by leading API providers. I take everything I find and publish here as part of my research.

I then take this research, and what I've learned and publish stories on the blog, and more long form content like my industry guides, and white papers for customers. This is one way that I generate revenue to keep it all going.

If you'd like to see me focus more on API plans I could use more partners investing in this area, helping me find the time to study more about what is going on. Feel free to contact me directly if you want to talk more about API plans.

Thanks for your support!