At the heart of Merge’s product is our Unified API. While the concept of a unified API (i.e. Plaid for banks) is not new, the design and implementation of what makes a good unified API is far from established. 

We built our Unified API around a single philosophy: normalization enables speed. Our customers are developers building cutting edge B2B tools, and integration roadmaps that take quarters to complete are usually not an option for the enterprise customers they serve. 

Our Unified API is Merge’s answer to this - if we can make it effortless for customers to add integrations, then our customers will be able to focus on building an even better core product.

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 an 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:

Available actions: Our Available Actions endpoint tells you what operations (GET/CREATE/DELETE) are supported for each model for a particular integration, as well as any required inputs.

For example, if Lever requires an email address of a candidate that you want to create, Available Actions will allow you to programmatically customize your request body, instead of you diving into the documentation to figure this out.

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

The above is our thesis on what makes a great unified API. But how do we at Merge apply these concepts to the 45+ integrations we offer?

Our Platform team.

Platform at Merge 

Merge Platform’s mission is to act as the vanguard of our integration capabilities. Platform accomplishes this by focusing on two critical areas: integration strategy (scoping and building new integrations) and product operations (integration quality and testing). 

The heart of the Merge product is our Unified API: the data that developers access from over 45+ platforms across 3 categories. We’re constantly thinking about new platforms we can add as part of our integrations. Whether this means designing new tooling for internal use, adding or expanding new categories of B2B integrations we can offer, the Platform team ensures that our customers are able to get the most comprehensive suite of integrations possible. 

Oh, did we mention we’re hiring?

‍