What is a unified API?

A Unified API is a single, aggregated API that provides access to the APIs of multiple software providers in the same software vertical (such as HR or accounting). Unified APIs also provide an abstraction layer that simplifies authentication, data transformation, syntax, and data syncing. 

Unified APIs exist to make it easier for developers to build integrations with many similar software products, for example multiple accounting systems, but which each have their own distinct APIs. Unified APIs are particularly valuable for customer-facing integrations, as they typically require support for a wide diversity of software providers (companies use many different accounting products), each with a standard set of customer-facing functionality.

Key capabilities of a Unified API

Unified APIs are an additional layer of abstraction that brings a variety of benefits to developers. There are three key capabilities that Unified APIs share. 

Unified APIs:

1. Authenticate and authorize the integration between your product and each of your customers' accounts across software providers
2. Normalize data across software providers' APIs so that you can GET, POST, and PATCH data in a standard and consistent format
3. Offer standard endpoints and methods to retrieve data, process responses, and handle requests

Authenticate and authorize 

A Unified API is dependent on software integrations with each of the software systems it normalizes data from. Each system, itself, may handle authentication in a different manner. As a result the Unified API provider must provide its users an abstracted system of authentication for each of integrations that the API provides. Examples of authentication methods range from simple authentication, to OAuth, OAuth 2.0, or platform-specific forms of authentication.

For example, Merge uses a standardized system of token exchanges to allow its users to manage one form of authentication, regardless of the third-party platform to which data is being pulled from. To see their process, read more about Unified API authentication.

Normalize data

Unified APIs maintain opinionated, representative models of data for each category of software and normalize data from each provider into these standardized data schemas. The Unified API makes decisions around what data is common across a given category, and how best to store it. This is due to there typically being inconsistent model attributes across API providers in a given category.

As an example in the HRIS space, an employee’s first and last name may be represented in BambooHR with the fields ‘firstName’ and ‘lastName’, while the ‘Employee’ model in Hibob may have a ‘fullName’ field. The Unified API provider would make a decision on how to represent first and last name across integrations, such as denoting an employee’s first and last name as ‘first’ and ‘last’.

The size and scope of standardized data models vary depending on the market that a Unified API addresses. For example, Plaid, a Unified API for banking, is based around just two data models: a ‘bank’ object and an ‘employee’ object. Merge has anywhere from 8 to 30 data models for a given category.

Standard endpoints and methods

While the concept of endpoints is important to any API, a Unified API exposes endpoints that correspond to its standardized data model. Thus, a Unified API allows developers to access data from many API providers via a single set of unified endpoints and methods. To accommodate this, the Unified API provides endpoints that allow some basic CRUD operations (GET, POST, etc. for a REST API).

Related: Embedded iPaaS vs unified API

How Unified APIs are different from other integration approaches

Unified APIs are primarily an alternative to having development teams build each customer-requested integration individually. There are, in addition to DIY integrations, several other methods to approach the challenges of customer-requested integrations:

Embedded Workflow Builders (aka IPaaS) support a wide range of integrations and customizable workflows for data transformation. Unlike Unified APIs, Embedded Workflow Builders don't normalize data, so developers need to build each workflow to match the data schemas and API requirements of the software provider. Examples include Workato Embedded, Tray Embedded, and Paragon. 

Note, these embedded solutions have similarities to Workflow Builders such as Boomi, Celigo, Mulesoft, and Zapier. However, embedded solutions are built for customer-facing integrations, whereas Workflow Builders focus on integrating systems internal to a company.

Integration Marketplaces (IMaaS) focus on distributing and monetizing integrations. Unlike Unified APIs they don't normalize data, standardize API endpoints, or sync data, so developers must build all of this functionality for each software provider they want to integrate with. Examples include Pandium and APIHub.

ETL or Reverse ETL tools that stream data between SaaS applications and databases or data warehouses. They work using data connectors, rather than APIs, and don't normalize or data across SaaS sources or destinations. Examples include Airbyte, Fivetran, Census, and Hightouch.

Why use a Unified API 

Unified APIs are designed for development teams to quickly and easily build out integrations. They are a best fit for teams that will need to build out several integrations of a similar type (e.g. multiple CRM systems) based on customer and market demand.

Is a Unified API a good fit for your app? Here's three key indicators:

• Your customers want integrations to your app
• You need multiple integrations of the same type
• You don't have time to build all the integrations you need

Related: 5 reasons why you need to invest in a unified API solution

Your customers want integrations to your app

Unified APIs are customer-facing, meaning that they help your customers connect their systems to your app. If your customers are asking for integrations, or your competitors are offering integrations and you're behind, a Unified API can be a great way to meet customer needs.

You need multiple integrations of the same type

Each software provider has their own API format, and while standards such as OpenAPI exist, interacting with APIs from two different software providers will always yield different results. 

Unified APIs normalize data across similar types of software. If your customers use different systems, say accounting systems, and want you to integrate with each one, a Unified API is a great fit. A Unified API, in this case, would make it easy to offer integrations with Netsuite, Xero, Quickbooks, and more. Every category of software products has many players, and as your customer base expands, you'll find integration needs continue to increase.

You don't have time to build all the integrations you need

Let's recap:

Your customers want integrations, and they want several different integrations. Why not just build the integrations with your development team? That is certainly an option.

Most development teams find that building integrations in-house is expensive, blocks other critical projects, takes a lot of long-term maintenance, and—let's face it—is not the engineering project most engineers are excited about. 

Unified APIs exist to make the up-front integration build and the long-term integration maintenance much easier, so your engineering team doesn't need to spend time on integrations.

Unified API Examples

Over time, the Unified API approach has expanded from fintech, with Stripe for payments and Plaid for consumer banking, to broader SaaS applications. Unified APIs exist for email and calendaring from Nylas and accounting, CRM, HR, marketing automation, recruiting, and ticketing from Merge (that's us!).

Real world examples of Unified APIs powering product integrations:

Lucid built out entire sections of their integrations marketplace using a Unified Ticketing API for project management tools. This helps them differentiate in the competitive collaboration market and increase customer retention.

Kona, a people analytics platform, offers dozens of HR, payroll, and benefits integrations using a Unified HRIS API. They use these integrations to drive customer acquisition, including a launch announcement on ProductHunt, and improve the speed of customer onboarding.

Care Friends, an employee referral app, integrates with 20+ recruiting systems using a Unified ATS API. They use ATS integrations to make it seamless for employees to find open positions at their company, refer candidates, and then track their progress.

What makes a good Unified API?

A good Unified API offers normalization, flexibility, transparency, and automated responses. 

Normalization 

Building a single integration takes a lot of time, but usually you need several in order to have a viable product offering. In addition, the categories Merge integrates with are not only complex; different platforms can return data through their API in very different ways.

A good Unified API normalizes as much as possible - if you’re building a B2B product and need to add at least several integrations, the unified API will do the heavy lifting of understanding the different schemas, authentication, pagination, and any other quirks that a platform will have. 

Let's take an example. Almost all applicant tracking systems (ATS) allow you to have a candidate apply to a job. A candidate might be a singular object in your mind, but every ATS can structure it in its own unique way. Some have separate representations of a candidate, application, and job, while some combine candidate and applications, but keep job postings separate. 

If you’re interacting with Merge's set of common models for ATS, you don't need to keep track of these different representations. Instead, you focus on a single schema - our understanding of the most important data that gets returned from an ATS. 

Normalization goes beyond objects, however. With Merge’s normalized data you get:

• One data model: normalized from the 20+ integrations that we research and analyze. You only have to interact with one schema. 
• One type of authentication + pagination: No OAuth, no weird required parameters that force you to build custom logic into your codebase, and no constant back and forth. We handle the whole process for you.
• One style of API: Just REST. No SOAP, No RPC. We’ve seen it all, and we’ve built a layer of abstraction on top of all kinds of APIs out there.

Flexibility (where it matters)

Good Unified APIs normalize as much as possible, but sometimes we encounter edge cases that will require you to be adaptable. A large prospect wants you to make a custom query, or you're building POST requests for a platform that has a specific required field. 

A good Unified API should normalize data, but also have built in features that allow you to customize wherever needed. Here are some examples at Merge that we’ve built into our API:

• Custom Objects: Define and associate custom objects to your data model.
• Unified Writes: Support any POST use case with our /meta endpoint, nested writes, and related writes.
• ‍Scopes: Delimit which data you want to sync at the model or field level‍
• Supplemental Data (Passthrough): Sometimes it’s helpful to be able to make requests directly to the system you’re integrating with. With Supplemental Data, you still get the benefits of Merge’s normalized authentication & pagination, but more flexibility by directly interacting with the system you’re integrating with. 

Transparency

A good Unified API can be a useful layer of abstraction on top of the platforms it integrates with — but it also shouldn’t be a black box. If there are situations where developers need to debug data that’s being returned from the system, having visibility can be extremely powerful to resolve these issues. 

Merge’s product and design goals align to balance simplicity with transparency in all aspects - especially when it comes to debugging the integrations our customers are adding. Through features that we’ve built like Outbound logs & Remote Data, both of which show you direct requests & responses we make and receive from the APIs we’re integrating with, we aim to enable transparency where it’s helpful. 

Automated responses

You'll come across two types of unified APIs: those that offer automated responses and those that provide them manually. In the case of the latter, the vendor is essentially addressing each API call manually, which inevitably takes time (e.g. a couple weeks) and introduces potential human errors. If you constantly need accurate data, you'll want to only invest in automated unified APIs.

If you're looking to go deeper on Unified APIs, including how they work, pros and cons, an evaluation guide, and alternatives, download the Guide to Unified APIs.

{{blog-cta-100+}}

Unified API FAQ

In case you have any more questions on unified APIs, we’ve addressed several more below.

What is the difference between a composite API and a unified API?

They’re fundamentally different; a composite API lets you bundle several API calls into a single request, while a unified API lets you offer multiple customer-facing integrations in a given software category. 

What is the difference between a unified API and a universal API?

The two terms refer to the same concept and can be used interchangeably. You might also come across analyst firms, like Gartner®, that refer to a unified or universal API as an API aggregator.

What are some common unified API companies?

The list includes vendors like Merge, Finch, Codat, and Apideck. 

While each vendor offers a unified API, their platforms are often significantly different from each other. These differences span everything from the categories of integrations they support to the endpoints they can access to the integration management tooling they provide out-of-the-box.