Connecting AI to APIs in a Standard Way
What are the different ways of standardizing how AI connects to APIs?
The biggest hurdle with integrating AI with APIs is building custom connectors. Ask any developer, and they'll tell you the biggest cost of integration is at the beginning, when they need to create a custom connector. Even API documentation is often presented around the use case of building integrations. The goal of API owners is usually to attract developers to build integrations. The cost of switching to another API is high, not because the right capabilities aren't present. It's because it's hard to build another integration from scratch. What if I tell you there are other, better, easier ways to create integrations where you don't need to write code specific to each API connector? Keep reading to learn more.
This article is brought to you with the help of our supporter, Apideck.
Apideck helps you integrate with multiple APIs through a single connection. Instead of building and maintaining integrations one by one, use our Unified APIs to connect with hundreds of leading providers across Accounting, HRIS, CRM, Ecommerce, and more.
All connections are built for secure, real-time data exchange, so you can trust that the data you access is always accurate and protected.
Ship integrations 10x faster, reduce dev costs, and accelerate your product roadmap without the integration bottleneck.
If you're a developer, you must have felt the pain of having to integrate with a new API. You started by understanding the use case, then you had to find the API capability that fulfills your business needs, and finally, you'd need to understand the API operations that implement the capability you're interested in. After all this, you still had to write code on your side. Sometimes you would write the whole integration from scratch. In other situations, however, you could just integrate your code with the API's SDK. Not that it made things easier. Au contraire, actually. In many cases, an SDK is not a mirror of the API itself but a representation of the use cases the provider thinks are interesting. And, unfortunately for the developer, the use cases implemented in the SDK might not be all that interesting. Altogether, it's easy to see that building an API integration from scratch is not a walk in the park. Wouldn't it be great if there were an easy, standard way to build an integration with any API?
Fortunately, there are a few options to build API integrations in a standardized way. One option is having a unified API or SDK that acts as a middle layer between the client and a group of APIs. This solution works great for APIs on the same vertical or offering similar solutions. As an example, unifying all invoicing APIs can be a good idea. As a developer, you only need to learn how to integrate against the unified API, not the different invoicing services. The friction to switch to a different vendor disappears, and the learning curve is flattened. There are various unified API options, both commercial and open-source, allowing you to choose the one that best suits your use case.
While a unified API is an interesting solution, it's not specifically designed for interacting with AI. For that, you have the Model Context Protocol (MCP). In simple terms, an open-source JSON-RPC API that acts as a proxy between AI agents and the APIs they want to access. Now the goal is not to facilitate the work of developers who build integrations with third-party APIs. Instead, it makes it simple for an AI agent to interact with external services. Because the MCP interface is always the same, AI systems don't have to "learn" how to communicate with different APIs. The whole process feels lean and cost-effective, from a development perspective. Speaking of development, can you have the best of both worlds somehow, where both AI agents and developers benefit? Read on.
Suppose you want to give your AI system the ability to work with several invoicing services in your company. To avoid the high cost of integrating with various invoicing APIs, developers can take advantage of a unified invoicing API. Instead of building several invoicing integrations, they can just build one that will work across the spectrum of existing systems. Now, if the integration is built inside an MCP server, it becomes automatically available to any AI agent that connects to it. Because the integration is unified, it uses terminology that is generic across the invoicing solution space and not specific to one particular API. Interesting approach, but it might have some drawbacks.
One challenge of having a unified invoicing API is related to changes. Whenever any of the invoicing APIs change, you need to make a change to the unified API. While it might sound simple when you have a couple of invoicing services to unify, if the number grows large, things can get complicated. The other hurdle with a unified API approach is the maintenance of the middle layer. You have to make sure that the proxy service is always working and handling all the requests from the MCP server. In theory, this shouldn't be a big problem, but in practice, it means that you have yet another system to maintain. Fortunately, there are commercial API unification systems that abstract all this maintenance.
In summary, you can connect an AI system to APIs in a standard way by using a combination of MCP and API unification. Whether or not you install open-source components and maintain the whole system yourself is a question you need to think about. The cost of using commercial solutions can, many times, be lower than what you'd have to spend to make sure everything is always running.