An Overview of Unified APIs

February 12, 2024

What is a Unified API?

A unified API is an integration of multiple APIs into one service with one common interface and data-model.

The benefit of using a unified API is that it allows you to leverage the best features from each individual API without having to build out your own custom integration into each one. A popular use case for unified APIs is when you want to access your customers' CRM data in your application, but don't want to spend time building out all the different CRM platforms individually. Instead, you can use one unified API that supports all major CRM vendors like Salesforce, HubSpot, and PipeDrive.

What Are the Benefits of Using a Unified API?

Faster development:

Unified APIs enable developers to create new applications and services more quickly, so they can get to market faster.

Reduced complexity:

Unified APIs allow you to use one set of tools for all your data needs, instead of having multiple systems that need to be integrated and maintained separately.

Increased Total Addressable Market:

By supporting the largest number of 3rd-party vendors, you expand your total addressable market by enlarging your user-base that can use your application.

What to look for in a Unified API?

Abstraction & Unification

API Endpoints: A Unified API needs to have unified/common API endpoints for specific categories of integrations. That sounds obvious given the "Unified API" term, but most API solutions actually do not offer this. An API to get a list of CRM contacts should be the exact same regardless of which integration that it is getting data from (eg. Salesforce vs Hubspot).

Data-Models: Not only must API endpoints be unified, but the data models used by those APIs must be unified as well. A CRM contact object returned from Hubspot should have the same structure as a CRM contact object returned from Salesforce. The number of fields in those common/unified objects should be sufficient to satisfy your use case.

Authentication: The method to authorize access to your customer's data in third-party vendors needs to be simple to use and unified for all integrations. Common information for the integration should be readily available so that your application can display it natively or the vendor should have an authentication widget.

Permission Scopes: Along with common/unified authentication, there should be a mechanism for abstracted permission scopes so that you do not need to research each vendor's OAUTH2 scopes for your use case

Webhooks: Finally, while some vendors support webhooks, most do not. A Unified API solution should abstract all of the complexities of handling those vendors that do not support webhooks and provide a unified webhook experience.

Ease of implementation and Maintenance:

How fast can you build a prototype using the Unified API? How fast can you scale that implementation in your production environment?

Do they provide rich detailed API Documentation? Do they have API Explorers that allow you to test each of the APIs?

Do they support a modern, easy, and logical API endpoint path format that makes it easy to build and understand?

Will you need to handle any external connections to vendors that isn't handled by the Unified API vendor?

Will you need to rebuild or update your integration into the Unified API vendor when they release a new version?

Security:

You want to make sure that the unified API vendor that you choose has a good track record of keeping data safe and secure and has processes in place.

Look for:

• do they encrypt their database, especially for OAUTH2 client credentials (clientId/clientSecret)?
• can they store your customers' access tokens in an external secure external storage (eg. AWS Secure Manager)?
• do they store any of your customers' 3rd-party data at all or do they just have that data transit through their systems?

Reliability:

Your app needs to be able to rely on the Unified API provider being there when it needs it, so look for a company that has an SLA and process to notify its customers when something isn't right. Where is the Unified API vendor hosted and how have they scaled their system?

Does the Unified API vendor know when a third-party vendor connection isn't working before your customer does?

Scalability:

When your app becomes popular, then you'll need an API that can scale with demand — otherwise, your users will have trouble accessing the service or worse yet get frustrated with slow response times as traffic increases.

Customization & Branding:

Because Unified API companies are providing an underlying technology for you to better build your application, their technology needs to be hidden to your users. Choose a vendor that allows you to use your own branding, including OAUTH2 credentials.

Transparency:

Trust is paramount for you to include a Unified API vendor's technology inside of your own application. To that end, you need them to be fully transparent with you. This includes:

• overall system uptime
• current errors in their system (and when they will be resolved)
• which integrations are appropriate for your application's use case (and which one aren't so that you don't offer then to your customers and have them disappointed)

Use Case Compatibility:

Not all Unified API vendors are similar as not all of them will support the use case that your application requires.

Some applications will want to only read in the name and email of a customer's Contacts in their CRM. But may need a large number of supported vendors in any one category (eg. CRMs). The number of supported vendors in any one unified API category is called Breadth.

While other applications will require a lot more fields in the common data-model. For example, an HR application may require the Employees' vacation history, date-of-birth, and years of tenure.

The number of support fields in the common data-model is called Depth. More complicated use cases will require more depth.

Does your application require more than one API category? For example, if you are building a customer monitoring application, you will want to synchronize with your customer's CRM, Support Ticketing, Call Center and probably even Marketing Tech vendors. All to get an accurate "picture" of your customer's customers. Unified API vendors who support multiple vendor categories focus on Clustering of a common object (in this case, a customer).

Pricing Models and Cost at Scale:

While most Unified API vendors have a free pricing tier, what is important for the success of your application is how much will this cost when your application grows and scales?

Consider what % of your selling price will be taken by the cost of the Unified API vendor.

Consideration should also be taken by the actual pricing model; is it based on API usage, Connections, of Customers? And how does that compare to your application's pricing model? If you extrapolate out these two values on a graph or spreadsheet, you will clearly see if their pricing model fits your business model.

Check out Unified.to for the Best Unified API for your Use Case

We've built Unified.to with all of these criteria in mind. We are trying to be both best in Breadth (number of vendors supported), Depth (number of common data fields supported), while also delivering common API vendors that are in a common Cluster. We've done this to support the most amount of use cases by our customers as possible.

We are also very security conscious and take your customer's data security concerns very seriously.

Let us know how we can better support you and your application's use case.