Who uses APIs?
It's time to make APIs easy to use by anyone.
“APIs are not something reserved for developers and the technology industry,” I wrote in my book, Building an API Product. This was in 2024, and, since then, this trend has been growing. Even more with the growing popularity of AI agents and MCP. According to the latest industry surveys, only 48% of API users are developers. Also, the variety of roles has been increasing to include users who traditionally were not associated with API consumption. Even the list of industries where those users come from has been growing in diversity. We now see consumers coming from fields such as advertising, education, manufacturing, and retail. What does this mean to you, and why should you care? Keep reading to learn more.
This article is brought to you with the help of our supporter: Speakeasy.
Turn your API platform into an AI platform with Gram by Speakeasy. Create tools from OpenAPI, curate into custom toolsets, and deploy hosted MCP servers.
Everyone uses APIs. But, they do it mostly indirectly. Contrary to what many people in the industry suggest, API consumption is not typically done directly. Yes, people often use a client to access one or more APIs. But compare those interactions with all those that happen indirectly through the applications that sit behind each integration. We’re missing a great opportunity, as API practitioners. Why do we prefer to insist that APIs need to be something technical and complex1, while everyone else seems to be going in the opposite direction? The opportunity we’re missing is manifested in things like MCP and agentic workflows. Of course, those technologies feel like a threat to many in the API industry because they show that anyone can use APIs in a simple way. It’s time to promote simplicity and open APIs to a much broader audience. It’s time.
Companies like Boomi, IFTTT, n8n, and Zapier have been making integrating APIs feel as simple as drawing a diagram2. Together, they reach a combined audience of more than 30 million users worldwide, bringing in an approximate ARR of approximately $900 million in 2025. And, this is not even scratching the surface of an estimated total iPaaS market share of around $15 billion. There’s clearly both room for growth and for new players to enter this market. These companies clearly see something that many API practitioners don’t. Instead of focusing on the technical difficulties of integrating multiple APIs, they hide all that behind the simplicity of a graphical UI. And, trust me3, that’s not easy to achieve. If many things can go wrong when connecting to a single API, imagine abstracting all the possible scenarios of tethering several APIs together. And, abstracting is something that, apparently, AI systems can do well.
Judging by its popularity, AI agentic workflows seem to be the natural successors to the procedural way of defining multi-step API connections4. Not only can AI agents identify what the best APIs for solving a given problem are, they can also react to errors and look for alternative connections. Many iPaaS companies quickly adopted AI agents as something that users could include in their workflows. At first, the technology wasn’t reliable enough for everyone, but it quickly matured into something dependable. And, a big part of this maturation was due to MCP5. You can think of the Model Context Protocol as nothing more than a director, routing requests to and from the best API operation for each problem it needs to solve. So, instead of having to build the workflows by hand, now users can simply delegate that job to an AI agent that will rely on MCPs to discover what API operations to use. Again, the path we see is towards reaching a broader audience. In this case, users don’t even need to understand what a workflow is. They just have to know what problem they want to solve and explain it in natural language. It’s obvious, at least to me, that MCPs have been hugely popular. In October 2025, there are more than 15,000 MCP servers available to users of AI chat systems and iPaaS products. So, how can the API industry copy MCP’s popularity?
The first thing we need to make APIs feel less technical is to reduce the friction to access them. If anyone can easily find an API, they will feel APIs are something they can directly use without effort. We don’t even need to reinvent the wheel here. We can just copy what MCP did when they launched their official registry6. Something else that also helps reduce friction is offering a way to try the API before signing up to use it. If users have a simple way to interact with the API, they will experiment7. While these two things alone would make it easier to find and start interacting with APIs, they’re not enough to make APIs something anyone can use directly. To reach that level, we’d need to have a much simpler API client. One that feels as easy to use as a Web browser. One that doesn’t feel technical, if you know what I mean. Someone has to simplify the API client by trimming everything that’s hard for a non-technical user. The client has to offer API discovery baked in, so users can start from scratch to easily find the operations that solve their problems. Some API experts think this approach reduces APIs, making them feel less powerful. If anything, what this approach does is amplify the power of APIs, not reduce it.
“Who will create this non-technical API client?” is the question I have burning in my head right now. Companies that already have an established technical user base might find it hard to introduce such a simple offering. On the other hand, new entrants and startups just beginning their product discovery process might be the best candidates for taking the bet. Technically speaking, it shouldn’t be hard to build an API client. However, the biggest challenges are related to product design. Whoever builds this simple, non-technical API client will have to excel at product design. They’ll have to fully understand the target audience, their needs, their jobs-to-be-done, their challenges, and the tools they currently use. I’d bet on a team of product and design folks over a very technical group of people.
Whether or not someone will build a non-technical API client remains to be seen. Not doing so is wasting the opportunity of tapping into an audience that’s much broader than the existing technical one. It’s also a way to guarantee that APIs continue to be relevant and something more people depend on directly. I’ll be here watching the space and rooting for whoever bets on non-technical users.
“I believe companies that are feeding on API complexity will have to change at some point. There will be new products unbundling what those more complex ones are offering. Those new products will offer a more simplistic approach to common challenges, instead of exacerbating them. What is now commonly seen as complex will become obviously simple,” I wrote in API Complexity is a Lie, September 2024. MCP, for instance, is a technology that makes the complex feel simple. Look at how some notable people in the API industry have been reacting to the growth of MCP, and you’ll see who’s living off complexity.
“Notably, companies such as Zapier and IFTTT have been able to capture a market segment where business users predominate. The simple UI combined with ready-to-use connections to business-related services has made these services popular among non-technical people. As a user, you can quickly set up an integration between the tools you use without ever touching one single line of code,” I wrote in The Relationship between No-Code and iPaaS, January 2024. These companies understand the needs of their users and have been molding the technicalities of integrating APIs into products that are easy to use.
I was the co-founder of tarpipe, an early iPaaS startup created in 2008. In 2011, before I sold the company, the product offered the possibility of integrating with more than 20 APIs. I was also the co-creator of CloudWork, a business-oriented iPaaS offering connections to around 100 APIs. In both cases, the goal was to heavily simplify any interactions that users can have with APIs.
“(...) unlike traditional workflows that follow procedural rules, agentic workflows can, among other things, make adjustments in real time whenever conditions change, make intelligent decisions based on constantly changing data, orchestrate multiple tools with little or no dependencies, and continuously optimize processes based on feedback loops,” I wrote in Are AI Agentic Workflows the Future of Automation?, January 2025.
MCP’s “original goal was to build ‘two-way connections between data sources and AI-powered tools.’ Its latest available specification at the time of this writing also mentions that you can use MCP to ‘build composable integrations and workflows,’” I wrote in Model Context Protocol vs. Programmatic Workflows, February 2025.
“How can we make APIs easy to discover by potential customers? One way is to publish information about those APIs in a place where potential customers can go to and find them. That place is the OpenAPI registry,” I wrote in The OpenAPI Registry, September 2025. Having an official API registry would be a significant step to increase direct use of APIs by a broad audience.
“What’s more interesting to me is having the ability to try the API right from the Web browser. This approach can take different shapes. Some APIs offer a button that lets you open an API client directly on the browser,” I wrote in Trying Is a Way to Learn How an API Works, December 2024.