“When you look at when you look more recently, we see companies that sometimes have 15,000 integrations, and there’s no way they’re building them all in-house. Since they don’t know which platform their customer is using, they need to offer all integrations to serve every customer—and that’s where the value of the unified API comes in.”
—Gil Feig, Co-Founder at Merge.
This week on the API Intersection podcast, we spoke with Gil Feig, Co-Founder of Merge, a company focused on building unified APIs that users can embed into their products and offer integrations to their customers. Merge offers one API to integrate with all HR, payroll, directory, recruiting, accounting, ticketing, and CRM platforms. During his enterprise engineering days, Gil noticed a constant need for companies to integrate their software with other platforms via APIs, so he sought to solve that problem via a concept called unified APIs.
A unified API (also sometimes referred to as a universal API) aggregates various APIs in the same software category. This makes integration easier because it offers a standard endpoint, authentication, and normalized data that the API can easily access.
We spoke with Gil to understand the significant benefits of a unified API approach and some of the downsides to help educate the community on if this approach is the right fit for your own API strategy.
Better Developer Experience and Ease of Integration
Utilizing a unified API approach can result in a consistent developer experience and less integration hassle for your internal team. It takes the pressures off of them and allows them to focus their innovations elsewhere.
“API companies have changed significantly over time, and we’re seeing more unified APIs. Companies need to build integrations with as many platforms that do the same thing as possible; it creates a lot of grunt work around building those connections again and again and having to go drag-and-drop,” shares Gil. “We’re seeing a lot of people actually move away from workflow automation and move back towards coding in-house because it’s not solving much of the problem. I think that’s one of the big reasons you’re seeing a lot of unified APIs popping up because it solves a lot of that grunt work.”
With the increasing demand for the number of platforms that users need to connect to, the number of integration opportunities and developer workload will only rise. Unified APIs can offer an improved developer experience and decrease the amount of time needed to build these integrations in-house.
Offloading Security and Upkeep Needs
“At Merge, we’re GDPR compliant and understand how critical, good security is. We have many options for our customers to store their data separately to meet their needs. We’re now able to work with some of the largest companies with really intense security programs,” shares Gil.
Exposing data externally can pose some risks. If you’re using a well-vetted vendor to conduct your unified API strategy, rest assured that security is handled well and that the upkeep of that API to remain secure and relevant is out of your hands.
“Think about authentication and permissions realizing that your customers are not just going to give you access to every single piece of data that exists within the API. You need to be able to handle what happens if data comes down and is missing or if data comes down and they’ve just formatted it completely differently from how we did it. So, it’s a lot of sustainability and the management, and not necessarily just updating a changing API,” shares Gil.
By outsourcing to a unified API vendor like Merge, that sustainability and management upkeep falls to them and off of your internal team. As long as your vendor meets your security requirements, then you should be set to proceed.
Other Benefits and Potential Downsides
Additional benefits to utilizing unified APIs instead of building your own in-house include fewer integration obstacles, consolidated documentation, a simplified webhook experience, a lower cost to maintain these APIs, and better standardization since you don’t need to make a billion APIs over and over again. Unified APIs also offer normalized data in a consumable format for easier ingestion.
However, unified APIs aren’t perfect and can also come with some downsides to be aware of when deciding if it’s the right fit for your team. You have to be careful with implementation because if a unified API is implemented incorrectly, it can cause significant issues and developer toil later on that are hard to unravel.
Additionally, relying on a unified API vendor means that you’re locked into having that vendor in your tech tool stack to make your process work. If budgets become tight or your team changes directions, that means you’ll always be at risk of not being able to support that external vendor providing your unified API service.
It’s always worth noting that it is riskier to have an outside source handling your APIs than an internal team. That also includes the potential data privacy risks you assume when adding an additional data processor to your tech stack. But, as I mentioned above, as long as you’ve ensured the vendor you use for unified APIs is ‘GDPR-compliant and encrypts data in transit to meet PSD2, CCPA, and other regulations’ (source), then you should be fine.
To Unify or Not to Unify?
“Whether or not you want to use a unified API, always think about your architecture and how you can do things in the future, even if it’s internally. That’s where the idea of Merge came from in the first place, shares Gil. “At our past companies, we had to build our own unified APIs and ingest them from different data sources, then translate them to a language we needed internally so the rest of our system could process that. So, the idea for Merge stemmed from us thinking about the future of our platform’s architecture and how we could make it better.”
Whether or not you decide the unified API route is the route for you, Gil’s advice to always remain forward-thinking is applicable regardless. Your API strategy should be well thought out, adaptable, and future-proof (a design-first approach can help with that). Personally, I can see the use cases for both unifying APIs and building them in-house–so rest assured there is a solution for everyone.
I enjoyed learning more about Merge and Gil’s journey, and for more insights about the API industry, you can subscribe to the API Intersection podcast.
