Unified API vs Embedded iPaaS: Which One is Right for Your Use Case?

As part of building your SaaS app, you have determined that you will need integrations with your customers' other apps. You've done some research, and it seems that a unified (universal) API or an embedded iPaaS might be the right starting point.

They seem to have similar functionality but are not quite the same. Does it matter? Is there an advantage to using one over the other? What are the similarities (and differences)? How do you know which one is right for your use case?

We'll answer these questions and more in the following sections.

What is a unified API?

A unified API connects several APIs in a common, typically horizontal, software category, such as HRIS, to a single API. This API abstracts the complexity of connecting to many systems into a single set of rules for connecting to one API, thereby simplifying the process of building integrations with those systems.

For example, a unified API might provide a single endpoint connecting thirty different HRIS APIs. Each HRIS has its own API (based on REST, SOAP, RPC, or something else). But the unified API allows integration developers to only concern themselves with the unified API's rules and architecture.

This abstraction also extends to the data schemas for each HRIS in our example. While each HRIS might have a different data schema for a record type, the unified API normalizes those data schemas to a single schema. For example, the Employee schema for the unified API may only have twenty attributes, though some source APIs may have Employee schemas with dozens of attributes. In addition, attributes in different schemas may have different names, data types, and relationships. These differences are all normalized via the unified API.

SaaS providers use these tools to improve the ease of building customer-facing integrations to multiple applications in the same category, such as accounting, banking, cloud storage, CRM, email, HR, payroll, or scheduling systems. Unified APIs can save teams significant time and resources when building numerous similar integrations.

A unified API includes:

• A single access point for integrations. Devs don't need to learn the intricacies of multiple APIs because that is all abstracted to a single API. Most unified APIs are based on REST (one of the simpler API architectures).
• Common authentication. The unified API handles the authentication for the underlying APIs, so the devs don't need to set up and maintain multiple unique auth connections. Having a single auth approach makes doing auth much less painful.
• Normalized data. Datasets from different systems are standardized and often slimmed to simplify building integrations without knowing the underlying systems' data schemas. This simplification means that devs spend much less time on data mapping.
• Consistent pagination and filtering. Pagination and filtering are based on the unified API rather than the underlying APIs. Over-fetching and under-fetching data are no longer issues.

What is an embedded iPaaS?

An embedded integration platform, or embedded iPaaS, is a set of tools that enables a software company to quickly build reusable, configurable integrations to any app in any software category and deliver them to its customers as a seamless part of its app.

It's called embedded because it has an integration marketplace that a SaaS team can white-label and embed in its products to create a self-activated, in-app integration experience for end users.

An embedded iPaaS is an end-to-end platform with everything a SaaS company needs to build productized integrations, deploy them to customers or enable self-activation, run them in production, and provide support.

An embedded iPaaS includes:

• A low-code integration designer. Allows non-developers to build integration workflows that can be configured and deployed to multiple customers.
• A library of built-in connectors (components). Provides connectivity to many common SaaS apps, built-in auth, and standard integration logic functions. Developers can also build custom components to connect with any app or service.
• An integration marketplace. Can be white-labeled and embedded in an app to provide end users with a self-activated, in-app integration experience.
• Integration deployment and support tools. Lets customer-facing teams configure, deploy, monitor, and troubleshoot customers' integrations.
• A cloud infrastructure. Runs integrations and handles scalability, security, and compliance concerns.

Which integration tool is best for your use case?

Both platforms are dedicated to simplifying the process of building API integrations. However, the approaches used to achieve this are quite different. And the capabilities of the platforms are also quite different.

Let's look at a few of these differences.

Do you need to integrate with one or multiple app categories?

A unified API combines the APIs within a common software category (such as HRIS, Accounting, or CRM). It can be a great option when you need to build integrations to 20 different CRMs. If you need to build integrations to a variety of app categories, you lose much of the advantage because you need to use a different unified API for each category.

An embedded iPaaS, on the other hand, is not tied to a specific app category but has everything necessary to build integrations with common apps, niche software verticals, or even one-off custom-built apps. Teams will need to build individual integrations for each system, but those can be expedited by standard connectors (available for many popular SaaS apps), and integrations can be productized (built once and deployed for dozens or hundreds of customers).

Do you need to integrate with uncommon or vertical-specific apps?

A unified API can be a good solution if you need to build a set list of integrations and you've verified that it supports all the apps you need. But you can't use it to integrate with apps it doesn't explicitly support. Some vendors will commit to adding support for an additional HRIS, for example, but that can take time. And if you need an integration to a vertical-specific app, you'll need to find an entirely different way to build it because these simply don't fit the unified API concept.

An embedded iPaaS, however, connects to each app's API directly using connectors. It comes with a library of pre-built connectors to common apps. Unlike a unified API, however, you're not limited to integrating with the apps on that list. If you need to integrate with less common apps or vertical-specific apps, you can build custom connectors that extend the embedded iPaaS and enable you to integrate with anything.

How complex will your integrations be?

When a unified API standardizes the data from the underlying systems into a schema, it establishes a lowest-common-denominator approach to the data. As a result, specific data from each underlying system is not accessible through the unified API. If you are using the unified API for data import, this restriction is generally not an issue.

But what if you need to process the data (combine data elements, strip out extraneous data, or convert units of measurement)in the integration? Or send notifications to various groups and individuals at different points in the integration process? Or what if you need to build a single integration with three or more APIs? Or combine data from multiple sources into a PDF and then attach the PDF to a record in your app? In each scenario, an embedded iPaaS provides the needed flexibility to make that happen. Because it's not standardizing underlying data schemas, an embedded iPaaS allows you to access and work with everything the source system API makes available.

How customer-configurable will your integrations be?

Unified APIs are designed for simple user connections. In a B2B SaaS context, your customer provides credentials and uses auth to log into the integration.

But what about the scenario where your customers' users, or even your customers' customers, need to connect to the integration as themselves? Or where an integration has many config options (frequency, metric or imperial units, multiple notifications)? Or a need for complex data mapping where you must split or combine data elements within the integration? Or how about needing multiple steps for a configuration wizard because several config options depend on other options? These scenarios need the configuration wizard and user-level-configuration capabilities of an embedded iPaaS.

Which of your teams will build the integrations?

A unified API makes it simple to build integrations by standardizing the API, the data schema, and authentication (among other things). Unified APIs vary in whether they include tools to build the integrations (or just the connecting point with the API). Some unified APIs provide integration connectors, allowing devs to start building integrations. In most cases, however, unified APIs are code-focused and require developers to build each integration, as well as create tools and processes for building, deploying, and supporting the integrations.

In contrast, an embedded iPaaS has everything needed to build, deploy, and support integrations. Non-devs (such as onboarding and support) can build the integrations and deploy, activate, and support them. Devs are only needed for building custom connectors or something else requiring custom code.

Choosing the right tool for building your SaaS integrations

If your use case is simple and a unified API provides you with the means of connecting to all the underlying systems your customers need, then going with a unified API makes sense. Similarly, if you don't have many integrations (or many customers for those integrations), then the development effort that comes with a unified API isn't that much.

On the other hand, if your use case is complex, an embedded iPaaS will provide a better integration strategy. An embedded iPaaS doesn't limit the integrations you can build or include additional restrictions for accessing data via those integrations. And having an end-to-end system makes things that much easier for all your teams, especially when dealing with large numbers of customers and integrations.

To make it even easier, ask yourself the following question: "Does the system I'm considering have the connectors (or capability for coding the connectors) for all the integrations we need for our customers – both today and in the future?" If the answer is "yes," you are in good shape. If the answer is "no," it's time for more research.

We work with SaaS companies all the time that need to provide in-app integrations. Reach out if you'd like to discuss your use case with us and determine if a unified API or embedded iPaaS would be best for you.