All of the existing API industry reports available today collectively fall short in providing the balance needed to understand the state, health, and wellness of the API space, which is a space that spans across almost every other business sector and impacts almost every aspect of our lives–raising the stakes considerably. Reports from Gartner, Forrester, and other analysts provide what enterprise IT decision makers need to assess the space, and SmartBear, Postman, and other vendors further augment this information with their vendor view of things from the consumer view as it pertains to testing, security, and an odd mix of other properties of our API operations. But to effectively understand the state of the API space with all of collective future in mind we need to begin looking at things with a more human-centered and vendor neutral approach that reduces the emphasis on just selling API solutions and feeding sales pipelines in this moment.
After being part of the Postman State of the API report, and seeing the removal of the section on specs in favor of AI in 2024 I wanted to assess the current state of API state reports and brainstorm what a more balanced and human-centered approach might look like-—the result is what I am calling The API Pulse, an ongoing API-first discussion around what information we need to make sense of where we all stand amongst our peers when it comes to producing and consuming APIs within our industry. The API industry is in need of accessible data that helps share knowledge regarding how we are all putting APIs to work while prioritizing the following dimensions of what we all need across our API operations.
- Vendor Neutral - You aren’t to be sold as part of engagement.
- API-First - Defined as an API first, then developed applications.
- Across Industries - Understanding across, but also within industries.
- Across Countries - Allowing for understanding adoption by country.
- Across Signals - Evaluating technical as well as business signals.
- Bi-Annual Reports - Summarizing and publishing reports twice a year.
- Ongoing Pulse Checks - Provide contributors with ongoing pulse checks.
I don’t believe we need yet another vendor API survey. The API Pulse hopes to ask many of the same questions you find used in existing API industry reports, but balanced across the different dimensions of API operations, communities, and ecosystems across many different industries—not just targeting those making buying decisions. Here is how I am hoping to balance the API Pulse to better capture what is happening in a way that benefits more than just people purchasing API solutions within enterprises, the companies that sell these solutions to them, and a handful of middlemen who enjoy their position of power.
- Individual or Organization - The pulse is from a human reflecting their view or the organization they work within.
- Producer or Consumer - The pulse is from people who are producing, but also the consumers of those APIs.
- Business or Engineering - The pulse is from people who are business, as well as engineering API stakeholders.
- Private, Partner, and Public - The pause can be from inside or outside of the enterprise for a variety of reasons.
All of the current API industry reports focus on the decision makers within the enterprise, which leaves out people in between organizations, as well as everyone else actually involved in producing and consuming APIs. The API Pulse begins with the two most important signals we can tune into to understand how APIs are being used.
- People - Engaging across many different roles to understand what is happening.
- Organizations - Allowing people to represent organizations via corporate emails.
Then of course the API Pulse will move onto the common technical bits you will find via other API industry reports, allowing people to share how they are applying the most common API protocols and patterns inside and outside the enterprise. The goal is to break signals up by the most dominant API patterns, organizing what is needed as a group of signals for the API pulse.
- HTTP APIs - Understanding the most dominant pattern in use.
- GraphQL APIs - Make sense of the impact GraphQL has had.
- Event-Driven APIs - Define what event-driven means to people.
- Schema - Defining how the digital bits are being defined.
Additional technical signals may be added in the future, such as Web Services and RPC, focusing on the pattern over specific protocols, but still drilling down into specific protocols in use. These are the technical bits that business stakeholders are going to be interested in, but I also want to to build more of a bridge between the technical and business aspects than you will find in any of the existing API industry reports.
- Access - Assessing the accessibility of all different types of APIs.
- Authentication - Getting a baseline for authentication of APIs.
- Contracts - How business and technical details are tracked.
- Distribution - Mapping out the distribution of different APIs.
- Experience - Understanding what the experience is for people.
- Governance - Tracking on how APIs are being governed.
- Plans - Looking at API value exchange and being monetized.
- Properties - Looking at the most common properties of APIs.
Additional business signals can be added in the future, but these signals reflect what is captured across existing API industry reports and reflects the signals aggregated as part of ongoing API Evangelist work. The plan for getting the API Pulse up and running has the following current timeline, which I will be looking to evolve and iterate upon twice a year.
- Feedback - Gather feedback on the proposed schema until March 4th, 2025
- Beta Release - Operate a beta release of the API until March 25th, 2025.
- Public Release - Gather API Pulse signals until May 8th, 2025.
- Publish Report - Publish the first API Pulse report on May 15th, 2025.
This is the road map as of today, but will change based upon work accomplished and ongoing conversations. Ideally we widen the public release as much as possible to get as many people involved as we possibly can. You can view the entire schema for the API Pulse on GitHub, and leave comments via issues, discussions, and feel free to submit PR. If you have any questions feel free to email me directly at [email protected].
I am very keen on keeping things simple, low-tech, while not worrying about getting everything 100% in the first version, accepting that we can try again in the fall, keeping the heart beat going while versioning the schema. The API Pulse should be a regular heartbeat of people who is doing APIs across every industry throughout the year with actual API year over year progress that does not simply go away because a startup got acquired or a startup CEO loses interest in what truly matters to people on the ground within enterprises, small businesses, government agencies, and startups.
