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). Rather than interact with the API for each software provider, Unified APIs 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 four 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
4. Sync and store data on your behalf, once it has been normalized

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

Sync and store

Unified APIs typically sync data at regular frequencies from API providers and store that data to make available from the Unified API's endpoints and webhooks. Unified APIs are architected to sync and store data, rather than as a passthrough layer, because each API provider has a variety of API methods and behaviors that would make a simple passthrough layer non-performant. 

For example, retrieving all the CRM contact records from two different APIs may be achievable from a single bulk API endpoint from provider A, but may require making multiple API requests and paging through results from provider B. Unified APIs sync data, therefore, to not only normalize the data schema, but also to normalize the behavior of underlying APIs. 

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 additional 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

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 has three things: normalization, flexibility, and transparency. 

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. 

Additional Unified API Resources

If you're looking to go deeper on Unified APIs, check out these essential articles:

• How Unified APIs Work
• Unified API Pros and Cons
• Unified API Evaluation Guide
• Unified API Alternatives

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+}}

Note: This post has been updated to reflect changes to the Unified API market.