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 a unified API (also called a universal API) or an embedded iPaaS might be the right starting point.

These tools have similar purposes 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, or unified API platform, 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). However, 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 schema 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. Universal 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.

Intrinsic limitations of unified APIs

Suppose we have an API that provides access to a data schema with 100 attributes (fields). Via the API, each of these attributes is accessible.

Now, let's add a unified API that permits access to two underlying apps, each with 100 attributes. But, they only have 92 attributes in common, after data mapping, etc. Our unified API provides access to those 92 attributes.

If we were to expand our unified API to handle 20 different apps, the list of overlapping attributes might drop to 60. And that's why the breadth of data available via a unified API shrinks as the number of underlying systems increases.

This also explains why users have one unified API for CRM apps and another unified API for Accounting apps. The relatively small number of overlapping attributes between CRM and Accounting means a single unified API would not work.

What is an embedded iPaaS?

An embedded iPaaS, or embedded integation platform, is a set of tools that enables a SaaS 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 product.

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.

A unified API is designed to help SaaS companies quickly build many simple category-specific integrations. On the other hand, an embedded iPaaS is designed to help SaaS companies create complex integrations that are easily configured and promptly deployed to numerous customers, regardless of product vertical.

Unified API vs embedded iPaaS

Here's a brief comparison of Prismatic's embedded iPaaS and a generic unified API.

{" "}

Now, let's look at some of these differences in more detail.

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 universal 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.

While a unified API is designed to build several similar integrations quickly, an embedded iPaaS is designed to handle extensive deployments of a single integration but with unique user configuration to tailor the integration to each customer. An embedded iPaaS is built to scale deployment from a single instance of an integration to hundreds or thousands of integration instances.

Which of your teams will build the integrations?

A unified API platform 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 and 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 platform 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.