What is a Unified API?

Unified APIs have been popping up in the market over the past few years, and you may be wondering whether or not they are the solution to your SaaS product's integration bottleneck. 

A unified API generalizes multiple SaaS APIs into a single API, and uses the unified schema to reference each individual SaaS API’s endpoints in the background. 

Many SaaS companies see unified APIs as a quick way to integrate with multiple third-party apps, as they can define their integration logic once and have it scale across dozens of SaaS integrations within a category (such as CRM integrations or task management integrations).

Theoretically, this would be a gamechanger in terms of saving your team the time it takes to learn the intricacies of each individual API.

Yet the inherent differences that exist between the 3rd party APIs that your product will need to integrate will require you to make unfavorable tradeoffs should you choose to leverage unified APIs in your strategy.

In this article, we’ll cover the factors you need to consider to determine if leveraging a unified API is the best approach for your product’s native integration strategy.

TL;DR

• Unified APIs provide a layer of abstraction that references multiple APIs in a given SaaS category.

• For extremely simple and generic use cases, unified APIs can be a good solution for scaling across many integrations at once.

• Unified APIs only provide coverage for entities that are mutually shared across every 3rd party API that it supports, which limits the ability to build integrations that require platform specific features or endpoints.

• Even for shared entity types (such as a Contact), nuances between APIs can lead to many limitations for accessible fields.

• Leveraging an embedded iPaaS may be a much more scalable and future-proof solution for building integrations when compared to a unified API. 

• Certain embedded iPaaS solutions, like Paragon, abstract APIs on a 1:1 basis, come with a robust infrastructure that provides robust error-handling, monitoring, and auto-scaling capabilities, as well as many additional features that unified APIs cannot provide.

What are Unified APIs?

Building a native integration in-house directly with a 3rd party SaaS product’s API is both time-consuming and challenging. For every integration, engineers have to build authentication, comb through the service-specific API documentation, build the UI and configuration experience for the end-user, and  – and then continue to adapt their integrations to any API changes going forward.

Unified APIs as a concept emerged as a way to reduce the engineering headache associated with constantly learning the nuances, shapes, and nomenclature for each individual API, once for every integration.

A unified API provides a layer of abstraction that can communicate with multiple APIs simultaneously. From an integration perspective, this means that for the encompassed APIs within the unified API, you only need to define the shared set of integration behaviors once and have it instantly scale across all the supported platforms.

As an example, say your customers need your product to integrate with their CRMs. Well, there are dozens of CRMs that your different customers may be using - Salesforce, HubSpot, Pipedrive, and Zoho, just to name a few.

Rather than reading the Salesforce docs to learn how to build a Salesforce integration, then going through HubSpot docs to build a HubSpot integration, etc., you would theoretically define a single CRM integration that would then ‘generate’ all of those CRM integrations at once.

A unified API makes this possible via a generalized data model that spans across all 3rd party services covered by a unified API. For example, most CRMs have an object that represents a “contact,” although the object name may vary between the various CRM apps. 

Some may call it a Contact, others a Lead, or even a Prospect in some apps. And within those objects, you can have different nomenclature for the same fields, such as {FirstName} vs. {Fname}.

Rather than spending days figuring out how each API references that same object, the unified CRM API would present to you a single API that maps between the unique data model of each individual CRM, in a 1:m manner.

Vertical/categorical scope of Unified APIs

The depth of endpoint coverage that unified APIs provide is directly tied to the lowest common denominator of shared objects/endpoints that the encompassed APIs have. 

As a result, each unified API usually only covers a single app category, such as:

• A unified CRM API that integrates your product with Salesforce, Hubspot and Zoho etc.

• A unified accounting API that integrates your product with Quickbooks, Xero and Sage

• A unified task management API that integrates your product with Asana, Trello and Jira

Challenges with Unified APIs

On the surface, the value proposition of a unified API sounds great. Define the integration logic once for each category and instantly provide dozens of integrations in that category. Sounds like a silver bullet for tackling your never ending list of backlogged integration requests right?

But it’s not that simple.

Lack of extensibility

The only way that a unified API can provide a common abstraction over a class of applications is by catering to the lowest common denominator.

This creates an inverse relationship between the number of applications supported within the unified API and the depth of coverage it provides.

The more apps that are supported within a unified API, the more limiting the unified API will be.

To start, here are all the scenarios that a unified API will not be able to accommodate with their generic data model, or would require tradeoffs on the end-user experience:

One or more of the apps in the unified API has an object/field that others does not

• ie. HubSpot has a single Contact object, whereas Salesforce has Lead/Contact objects that behave differently.

• Workaround: Have customers who use Salesforce select the object they want the use case to map to, but ignore the relationship between Lead/Contacts within their application.

One or more of the apps in the unified API has mandatory/required fields that other apps do not

• ie. HubSpot’s Contact object only requires an email field to be filled out to create a new contact, whereas a Salesforce lead requires LastName, Company and Lead Status to create a new lead

• Workaround: Every integration in the unified API will have to ‘inherit’ required field behaviors from every other tool within the API. In the example above, Salesforce would inherit the required behavior for ‘Email’, and HubSpot would inherit the required behavior for ‘LastName’, which doubles the number of required fields for each service.

One or more of the apps in the unified API has a single field that refers to multiple fields in another app

• ie. one marketing automation system has Name, and another marketing automation system has First Name and Last Name

• Workaround: End-users may have to implement their own parsing automation to split the First and Last names and update the corresponding fields.

If apps have dissimilar features that are irreconcilable

• ie. One applicant tracking system may offer a candidate rating system with a score between 1-10, whereas another applicant tracking system may require a ‘Strong Yes, Yes, No, Strong No’ score that is coupled with comments.

• Workaround: No real workaround - even if the unified API provider injects an opinionated mapping between the scores and the qualitative rating, they will not be able to support the commenting functionality.

If the apps have different rate limits

• ie. One app’s API may limit your users to 20,000 requests/day, whereas another may allow for up to 100,000 requests/day

• Workaround: No real workaround - the lowest rate limit amongst all integrations in the unified API will be inherited by every other integration.

Limitations on available methods for different objects/fields

• ie. An object in one app doesn’t provide POST methods, whereas other apps referencing that same object does.

If any of the apps provide Custom Object/Field support

• If a user has the ability to define their own objects or fields within an application, there is simply now way for the unified API provider to incorporate that object/field into the generalized data model.

• Workaround: Build the integration use case outside of the unified API

With this in mind, if you can only support generic use cases with a unified API, you won’t be able to offer the truly integrated experience that your end-users need.

Additionally, unified APIs prevent you from building unique integration features for specific customers, as all features must be shared by all customers in a unified model. This will be a challenge if you ever sell to enterprises that have very specific and bespoke requirements.

And that lack of fidelity is a huge problem. If your customer has chosen Jira over Asana, or HubSpot over Salesforce, it’s because they see unique advantages of one solution over the other. They’re going to want to see the features they need in any integration they use, and unified APIs will prevent you from building into the strengths of any individual solution.

Security

Many unified API providers will also request all OAuth scopes from each integrated service rather than the least privileged set of them, because they do not have the ability to support integration-specific scopes. This is not ideal as you should not be requesting access to all your customers’ 3rd party data - only the data required to enable the use case for the integration.

Infrastructure

Unified API providers also do not provide the infrastructure required to execute the requests for the integrations that you build. This means that as you scale, you will be accountable for building concurrency into your integration architecture, as well as resiliency features such as auto-retry in the case that your integration encounters external errors on the 3rd party service’s side. In the long run, these are harder (and more expensive) engineering problems to solve that you may not want your team to work on.

What you can achieve with Unified APIs

Despite the limitations above, there will still be integration use cases that can be supported by every 3rd party service provider.

What you have to evaluate is what integrations you’ll need in the future, the use cases you need to support, and whether or not all of the required endpoints you would need can be supported by the unified API.

If you are 100% confident that every integration use case your customers will ever ask for are covered by the shared model, then it’s safe to use an unified API for your integration strategy.

However, in the scenario that you do need to provide unique functionality that is not provided within the unified API, you’ll have to build that in-house outside of the unified API.

This will become an enormous maintenance headache, and can even lead to unfavorable integration experiences for your end-users such as requiring separate OAuth flows for the same integration (one for integrations built in-house, one for integrations built through the unified API provider).

A more extensible alternative

If you want to build robust integrations that can unlock additional value for your customers, an Embedded iPaaS is a better choice than a unified API. 

While the embedded integration platform space has been crowded by many no-code, non-developer focused solutions, a select few are built specifically with developers in mind.

With an embedded iPaaS like Paragon, you’ll have access to:

• Fully managed (and white-labeled) authentication for any integration, with managed token refresh for OAuth based integrations

• Deep, integration specific 3rd party API abstractions

• Proxy API access to full depth of each 3rd party API

• A custom integration builder that enables you to build any integration on your roadmap

• A scalable integration infrastructure capable of handling millions of requests each month

• Robust monitoring and debugging tools

• Custom object/field mapping support

• Modern SDK and APIs for full extensibility of your integrations

As such, working with an embedded iPaaS will let you accelerate development of your integration roadmap, without compromising on the feature extensibility of those integrations - an inherent limitation that unified APIs are handcuffed with.

Conclusion

While unified APIs offer a compelling value proposition at first glance, their limitations generally outweigh their benefits long term. If you’re looking to scale your integration roadmap, embedded iPaaS platforms are a far better solution than unified APIs. Embedded integration platforms provide the extensibility you need to support all your customers' use cases, while providing you an infrastructure that you can rely on as your user base and integration roadmap scales.

See it for yourself – book a demo with us and you’ll see exactly why over 100 fast-growing B2B SaaS companies rely on Paragon for their integration strategy.

‍

‍