Not all API companies are the same: the 4 types
Gil Feig is the co-founder of Merge, a San Francisco-based startup that helps users build customer-centric integrations with third-party tools, providing access to over 50 systems and adding new platforms every week. Previously, Feig was responsible for engineering at Canvas and led projects at Wealthfront and LinkedIn. A Columbia University graduate, he lives and works in San Francisco.
The software has not always been connected.
The path to APIs
Thirty years ago, as applications became more and more entrenched in core business processes, most programs existed in silos. These on-premises (on-premises) solutions, hosted on personal computers (PCs) or in local data centers, were designed to fulfill small individual roles within the overall functionality of an enterprise.
An example of this comes from Core Solutions Group (CSG), which created accounting software for mattress companies in the 1990s. As customer needs increased over the decade, CSG changed its software to meet these growing demands. At the same time, mattress makers started buying software to power their mattress topper sewing machines. Previously, mattress manufacturers were forced to manually copy data on materials consumed and output produced from their machine software to their accounting software. This left room for errors and added operational complexity. By the late 1990s, mattress makers had at least two essential software packages: accounting and machining, but no immediate way for the programs themselves to communicate. While rudimentary solutions existed for communication between applications, they were nowhere near as robust as the era of application programming interfaces (APIs).
In the early 2000s, APIs began to flourish. Representative State Transfer (REST), one of the most popular modern API protocols, has been introduced. Yet while thought leadership has made the world think that “data is the new oil” and therefore should flow freely between applications, historically on-premises software has taken the opposite direction. The demands of corporate operations (siled data centers, stringent security requirements, and inflexibility of the compute scale) have pushed back the software in place. On top of that, the need to build APIs on software not originally designed with APIs in mind has turned out to be a huge undertaking.
In response to the growing need for interconnection between software, generations of companies have emerged to provide specific solutions to the general problem of integrations. The following four types of API companies represent the changing challenges and approaches to the current problem of integrating real-time data movement:
4 types of API companies
API Business Type 1: On-Premises to Cloud
The first wave of companies to emerge bridged on-premises solutions and the emerging new cloud.
MuleSoft and Boomi were, and still are, two of the most notable players in tackling the problem. They provided a combination of code toolkits and visual interfaces to remove much of the standard work around building APIs. Suddenly there was a bridge between on-premises and the cloud that didn’t require for-profit investments.
However, software engineering work was still needed to connect all of these new emerging APIs. Companies never have enough software development resources, so connecting internal APIs, like their accounting software with their machine software, has always been a challenge, despite all the communication interfaces available.
This lack of development resources has opened up the world to another category of API companies.
API Business Type # 2: RPA and Workflow Automation
Starting in 2006, with APIs following relatively consistent standards on a few protocols, such as Simple Object Access Protocol (SOAP) and REST, and engineering resources both expensive and scarce, companies emerged to allow anyone to connect APIs.
Although slightly varied in their approaches, the goal of these companies was to enable non-engineers to automate tasks, data movement, and data manipulation. UiPath, Tray.io, and Workato are three notable examples.
These platforms provide visual tools to extract data from APIs and user interfaces. Users can then manipulate and insert extracted data into other APIs and user interfaces. This process, also known as Extract Transformation Loading (ETL), immediately became cheaper to perform without the need for full-time software engineering involvement. Now, a person working in accounting at a mattress company could simply open Tray.io, choose to pull data from machines every hour, turn it into standard accounting metrics, and insert it into their Core Solutions Group accounting software. No coding experience is necessary.
But internal processes were only a small part of the equation. As cloud native software exploded, it became clear that forcing customers to build their own integrations, with or without no-code automation tools, was insufficient. Why force each customer to create their own automation if platforms, like Core Solutions Group, could create native integrations with complementary software and deliver them to their own customers instead?
API Business Type 3: Integrated Workflow Automation
As many companies began to develop native integrations with complementary software products, the work proved, once again, to be demanding. Software engineers had to develop each integration and deal with the many complexities introduced by the different data models and protocols between APIs.
Companies like Tray.io and Workato have introduced âembeddedâ solutions. With these, Core Solutions Group could easily integrate a UI component of Tray.io into their application and then build a generic visual workflow on their own. At this point, Core Solutions Group customers would simply enter their credentials into the built-in UI component and the pre-created workflows, invisible to the customer, would begin to run. This greatly simplified the integration process: the connections between the software had to be established only once, and the responsibility for these connections was transferred from the customer, the end user, to the product, the supplier of the connected software.
Unfortunately, one of the biggest challenges that remained was that a company like Core Solutions Group couldn’t predict what machine software their customers would use. There could be thousands of solutions used by mattress companies around the world, so even though automating integrated workflows requires less engineering, Core Solutions is still needed to maintain thousands of workflows for APIs that break, change, and add functionality over time.
API Business Type # 4: Unified APIs
In response to the problem of industry fragmentation, unified APIs have emerged.
Most notable in this space is Plaid, which provides a single API to connect to over 11,000 financial institutions. Before the emergence of Plaid and similar companies, building fintech applications was very difficult. Consumer data was spread across so many different banks that creating an app, like Mint, to help people understand financial health meant having a team solely focused on providing integrations with every bank possible that they could. ‘a user could use. Even with tools like UiPath to mine and mine scarce banking APIs, it was simply financially impossible to build all of the integrations needed to serve the masses.
Since Plaid, unified APIs have emerged across many verticals. Nylas provides a single API for all email and calendar clients, and Kloudless takes care of cloud storage, calendar, customer relationship management (CRM), messaging, chat, and accounting. . Depending on your needs, there is one for almost any industry, including HR APIs, Payroll APIs, ATS Recruitment APIs, and more.
When it comes to producing integrations for production-grade customers where end users are spread across a variety of competitors in a vertical, unified APIs are the easiest and most robust way for businesses to deliver integrations with each of them.
Integration solutions for everyone
The integrations industry is not universal. Just as credit cards and hedge funds in the financial industry are not analyzed competitively, the same approach applies to the wide variety of solutions within the integration space.
And while this article focuses on real-time data movement use cases, it doesn’t even mention solutions related to other areas, such as those that bridge APIs and data warehouses, Fivetran and Census, for example. As Core Solutions Group evolved to adapt to customer demands, they were given the opportunity to purchase new products.
No matter what a business use case, there is a solution to reducing the massive overhead costs produced by critical integrations. And as new issues and nuances emerge in the realm of integrations, there will always be new companies to bridge the gap and allow information to flow freely.
See more: Top 10 API Management Tools