What is a Unified API? And How to Evaluate One for Product Integrations

Kelly Sarabyn

With APIs taking over the world, more unified API companies are cropping up. But what exactly are unified APIs and do they work well for product integrations? 

A unified API is a “meta” data model designed to enable developers to talk to many other systems’ APIs through one interface. The lack of coverage for partner systems’ data fields and methods, opinionated and inaccurate data models, additional dependencies, and increased latency can all be reasons to avoid unified APIs for product integrations. 

In addition, a number of unified API companies may be using your customers’ credentials to screen scrape their data from their other accounts, and this can cause lasting damage to your customer and partner relationships.

Ultimately, unified APIs are best suited for product integrations when they are not screen scraping and when they cover a limited number of systems that have a high degree of similarity in their data categories and methods.      

What are Unified APIs?

The average business uses 110 pieces of software, which is a 9 fold increase from 5 years ago. And they have more and more systems to choose from: there are now 185,000 SaaS apps, projected to be 1m in 2030.

With businesses using so many systems, they need more efficient ways to move their data amongst these different systems. One key way that this data is moved more efficiently is through APIs. 

An external API (application program interface) is a contract that is set up between the SaaS application and the rest of the word. It provides a layer of data abstraction that enables systems to more easily talk to one another.    

APIs remove some of the work of developers having to understand the idiosyncrasies of each system. It also provides a layer of security, as a partner system does not need to directly access another system’s primary database. 

Most modern SaaS companies, once they grow past the early stage, offer a REST API to their customers and app partners. GraphQL and webhooks are also increasingly popular. Older SaaS companies may still use other styles and protocols of APIs, such as SOAP.

SaaS apps’ coalescing around certain API styles and protocols is itself an attempt to reduce the work of integration. Many developers have worked with the REST protocol, for example, and so do not have to learn how to work with it from scratch when they go to build an integration to a new system. 

OpenAPI Specification, which is a specification for REST APIs, is also increasingly used, making it even easier to work with and understand other companies’ APIs.

Even if a technically better style or API design comes along, a company has to consider the cost of finding internal and external developers who are willing to learn to work with this style. 

Companies usually want to encourage more partner and third party developers to use their external APIs. As a result, the market has naturally moved toward adopting common standards that developers are familiar with.  

So if APIs provide a layer of abstraction for systems to communicate with each other, what is a unified API? 

Unified APIs (also called normalized or universal APIs) aim to provide an additional layer of abstraction on top of other systems’ APIs and data models.

SaaS APIs already have standard styles and different categories of products tend to use at least a core of similar data categories. Most CRMs will have data resources for Companies and Contacts, for example. 

However, every system’s API will have its own idiosyncratic naming conventions, resources, rate limits, and field properties. They also may have different forms of authentication. A developer will have to learn these distinctions if they are building anything but a very simplistic integration.

The idea behind unified APIs is that they can save developers the time of learning the idiosyncrasies of each system. In theory, a developer can connect to a few or even dozens of other systems by just building an integration to the unified API.

Why Unified APIs are Vertical Specific

Unlike REST or OpenAPI, there is no unified API format or style that SaaS companies are choosing to adopt and follow. Instead, unified APIs are, at this point, proprietary data models imposed on top of other SaaS companies’ APIs or systems. 

As the number of SaaS companies proliferate into the hundred thousands, update their product and APIs faster than ever, and SaaS companies do not follow the data model of any unified API company, a unified API company must spend more time constantly updating their data model and relationship to each individual system.

Most systems are designed to enable different business objectives for different types of organizations. Flexibility and customization to the end business’s needs are critical to the software working as designed. Restricting this flexibility or customization can impede the point of the software. As a result, unified APIs must continue to update their model to accurately capture each connected system’s changes and updates.

For example, if a unified API does not contain resources or data fields that are required by a particular system to access core data, then the integration built on that unified API can become useless. 

An accounting system may have a resource for Items that were purchased. But it also may have further properties around those items: items grouped into particular Product Categories, or items that are part of a Bundle of items.

If businesses need to track these bundles and product categories to be successful and the unified API does not have any resource or field for “bundle” or “product category,” then the business will find the integration to be of diminishing value.

With current technology, it is not possible to write a unified API that accounts for even most of the important resources and properties in SaaS APIs across the entire market. As a result, unified APIs are focused on one vertical or product category of systems, such as email providers, financial systems, CRMs, or HR systems. 

Unified APIs are not proffering a new protocol or style, but rather a unified data model. If the underlying data is widely disparate and only has a 10% overlap in what they are referencing, for example, there is not much to unify.  

Accounting system APIs, for example, may have resources around invoices, bank accounts, balance sheet, cash flow, and tax code, while CRM APIs have resources around opportunities, deal stage, cases, lead sources, and forecasting.

Certain resources may overlap across verticals, like company or account resources, but as this overlap is minor, the value of “unifying” those resources for a developer would be small. They would still have to build the majority of the integration by working directly with each system’s API or system and thus have to spend the time to learn it.

But if a unified API is focused on specific verticals and specific use cases, it can unify the data in a way that speeds up development. APIs will often have different naming conventions to refer to the same concept, for example, and this is something a unified API can resolve. 

Quickbooks Online’s API refers to the attribute identifying what currency is being used by an Invoice as “CurrencyRef,” while the Freshbooks API refers to this as a property as either a “currency_code” or a “code,” depending on how it is being utilized. A unified API could make a property Currency and then when a developer makes a call to the unified API’s Invoice Object involving the Currency property, the unified API could then send this request to both Quickbooks and Freshbooks, changing the language to reflect each system’s distinct naming conventions.

Challenges in Unifying Disparate Data Models

Even in the same vertical, APIs often differ in ways greater than the naming conventions. Meaning there might not be a 1-to-1 relationship between resources or fields that simply requires re-naming. This can happen in a number of ways:

  1. One system has a resource or field that another does not (for example, a CRM has a Partner resource, and another CRM does not)
  2. One system has required fields for particular resources or fields that another does not (for example, a CRM has a Contact resource that requires an email field to be filled out to create a new contact, while another system requires a name, company and contact id to create a new contact)
  3. One system has a field or resource that refers to multiple fields in another system (for example, one marketing automation system has Name, and another marketing automation system has First Name and Last Name)
  4. Systems have irreconcilable resources or fields (for example, one ATS might have a Scorecard resource with a field that represents 6 different levels of endorsement while another may have Reasons for Rejection and Reasons for Hire with a substantive list of reasons) 
  5. Systems have different rate limits
  6. Systems have different available methods for different resources (for example, one ATS allows a business to post past applicant data to the candidate profile, and another ATS does not)
  7. Systems have restricted resources or endpoints
  8. Systems enable and business rely on custom objects

Unifying around these discrepancies can be challenging and in some cases impossible. One can’t reconcile data that refers to two different things in the world, for example. 

One solution to this is to add the distinct fields or resources of every system, but then return a null response from systems that do not have that field or resource. But this divergence obviously undermines the value proposition of only having to work with one API to create many integrations.

Another solution is to allow the developer to directly interact with the other systems’ APIs in addition to interacting with the unified API. However, this also undermines the value proposition as the developer has to then learn both the unified API and the other systems’ APIs to understand what is missing and how to directly call the other API to cover that missing functionality.

Other times, unified API companies may reconcile data in a way they see fit. For example, they may create a Candidate Rank resource with 4 ranking options (adamantly reject, reject, endorse, adamantly endorse) and then decide to put a system that has 3 rankings (never hire, hire, adamantly hire) into the 4 rankings by mapping never hire to adamantly reject, reject to null, endorse to hire, and adamantly endorse to adamantly hire.

As one can see, this is an opinionated model and may or may not capture the underlying intent well or accurately. However, it expands the reach of the unified API.    

Even with these limitations, vertical-specific unified APIs can be valuable tools for businesses who need to pull and push data from dozens of systems. These work best when the scope of needed data covered is narrower and the divergence amongst systems’ data models and underlying objects is lower. 

Assessing this as a business requires looking carefully at what data and actions might not be covered by using a unified API, and how hard it will be to add that additional data into the business’s workflows, or what the cost would be for not integrating that particular data.

Using Unified APIs for SaaS Product Integrations

Unified APIs have often been used by businesses to integrate the applications they are using internally. Mark’s Shoes, for example, would use a product like Segment, which, alongside other platform features, has a number of unified APIs focused on customer data, to pull all the customer data from the various accounts they have with website builders, chatbots, CRMs, email marketing automation, etc., and push it into their own databases and warehouses.

This has saved many developers’ time on managing individual system integrations. But a somewhat newer use case for unified APIs is for SaaS companies to use them to offer their customers’ out-of-the-box product integrations.

This embedded use case has the same challenges mentioned above, which is why unified API companies (like when they are aimed at businesses directly) are also vertical specific. But this use case exacerbates many of the challenges detailed.

A business using Segment for their own systems, for example, can spend the time to customize the platform and add whatever code and workflows they need to optimize their own workflows. The business is both using the unified API and is the end user for the resulting integrations.

However, if Luna Email Marketing Automation wants to use a unified API to offer its customers integrations to Salesforce, HubSpot, Netsuite, Pipedrive, and other CRMs, Luna is no longer the end user of the integration. Instead, they are using the unified API to try to provide integrations to multiple systems to multiple different business customers who are all using those systems in their own way. 

Luna’s customers are likely operating in a variety of verticals and industries and are different sizes. They have different needs and uses for their CRM. As a result, the desired use cases that are not covered by the unified API can multiply significantly. 

Moreover, if Luna wants to provide customers with the configurations for the integration that they need, this means either Luna has to work directly with the APIs of the other systems to offer this additional functionality, or customers essentially have to build their own integrations with Luna’s APIs and the CRM’s APIs.

In addition, the unified API must manage authentication processes for Luna’s customers’ accounts, instead of just for Luna’s account. When a customer goes to install the integration Luna built on the unified API platform, they are giving Luna, the unified API company, and the partner app access to their data in their other account.

It is widely accepted as best data security practice to request access only to the customer data that one needs for an integration use case and no more. However, some unified API companies targeting the embedded use case are likely not abiding by this principle. 

Unified API Vendors Building Integrations without APIs

SaaS companies build product integrations through using partners’ APIs or through strategic partnerships that grants them special access to data. Some unified API companies, however, appear to be bypassing systems’ APIs (or lack thereof) to grab data to power the SaaS product integrations. 

This appears to be because they want to provide access or increased integration functionality to systems that either do not have an external API or have a restrictive partner API. 

Unified API companies want to enable SaaS companies to build integrations to all leading software in their vertical. Their value prop is that they significantly streamline the process of building product integrations for SaaS customers. If they can’t “unify” key systems, the value diminishes. 

But in some verticals, APIs don’t exist, are only available to strategic partners, or have limited functionality for certain key systems. 

The question to ask is how these unified API companies are providing access to data in systems that, you, as a SaaS company, would not be able to access through an API. The answer is - unless they have a legal, documented strategic partnership with the system - it almost certainly can’t without impersonating Luna’s customers’ accounts via a browser and screen scraping them. 

So, for example, the unified API company would ask Luna’s customer Mark’s Shoes to authorize an integration between Luna and Salesforce. The unified API company would then use Mark’s Shoes’ Salesforce credentials to directly access all their Salesforce data and then scrape it so it can send the data back and forth to Mark’s Luna account.

If this sounds ill advised, that is because it is

If you’re a SaaS company considering using a unified API company to provide your customers with integrations, if the unified API company offers: 1) access to system APIs you can’t access directly 2) access to customer account data in systems without external APIs or 3) offers webhooks for resources when the other system has no webhooks for that resource, then you should demand a clear technical answer on how they are doing this.

Ask them how exactly they are getting access to customer account data without APIs or webhooks. If they claim to have special access to a system’s API or database, then ask them to show you proof of that legal relationship.

If they don’t have a legitimate answer for this, there is a real risk they are enabling the customer’s violation of their terms of service on sharing user credentials and taking and storing data from those accounts, which could have implications for the user, the unified API company, and the SaaS company that is enabling this data transfer.

If the other system detects this or finds out about it, they may reset your customers’ account repeatedly, hobbling the integration and the account. They may also choose to ban the unified API company and your SaaS company from ever being an approved tech partner. 

Plaid, a unified API company in fintech, recently agreed to a $58 million dollar settlement related to this practice. Part of the complaint against them stated that “at no time were users ever given conspicuous notice or meaningfully prompted to read through Plaid’s privacy policy indicating that Plaid receives and retains access to their financial institution account login credentials.” 

While Plaid (valued at $13 billion) can withstand a $58 million dollar settlement from a financial perspective, an earlier stage startup can likely withstand neither a significant financial settlement nor the damage to their brand in the eyes of their partners and customers. 

One of the terms of Plaid’s settlement is that they would avoid using the color schemes of banks when asking the end user to authenticate so that the end user would understand more clearly that they were handing their account credentials over to a third party vendor.

Of course for a SaaS company using a unified API vendor to offer product integrations revealing the third party app to their customers undermines the value of white labeling. It is not clear customers wish to turn over their CRM or ATS login credentials to a third party who they have no relationship to.

Plaid also agreed to commit to working with institutions’ APIs so that they did not have to rely on using the user’s credentials and screen scraping data. Indeed, the fintech market in general is moving more aggressively to condemn this practice. When non-disclosed, this type of account screen scraping has already been banned in fintech in Europe.

As a SaaS company presenting this third party vendor to your customers, often in the guise of being part of your product, it is important to ask these questions of a unified API vendor and understand the risks to your partner and customer relationships.

How to Evaluate a Unified API Vendor for Product Integrations

Not all unified API vendors provide access to other SaaS outside of available APIs and webhooks. 

When a unified API vendor is only covering systems who have external APIs or webhooks (or those which it has a legal partnership), there are other issues that should be taken into account before deciding to use a unified API for product integrations: 

  1. Lack of coverage for some data and methods (discussed in more detail above) - Consider the use cases different types of customers will have for integrations from your app to a particular product category. Assess how much the unified API covers the needed data and methods (for example, just posting a resource as opposed to posting and getting data from that resource). Map out how much your developers will have to learn and build to the partner system’s APIs in order to get to your customers’ needed functionality. If your developers have to learn the partner APIs anyway, layering a unified API on top of it, which they also have to learn, can end up a headache that saves minimal or no time.
  2. Opinionated Data Model - Assess whether the data model is taking disparate concepts and reconciling them into new resources or properties. Determine whether this undermines the end user’s business objectives and accurately captures business meanings and objectives.
  3. Latency - With a unified API, you build an integration or integrations to the unified API, and then the unified API builds integrations to the partner systems. By introducing an additional app in the middle of a data flow from your system to the partner system, you’re introducing a delay to when the customer gets and receives their data in both systems.
  4. Dependency - An additional app is introducing a whole new set of dependencies. If your unified API vendor is down or having issues, for example, then every customer-facing integration you built on it will be down too. In contrast, an integration built directly to, say, Salesforce’s APIs will only be impacted if your API or Salesforce’s API is down.
  5. Rate limiting - Consider how the unified API company handles rate limiting and how that impacts the integration design and data synced. If the company is only working with APIs, then they must abide by partner’s rate limits. How do they handle when one system in a product category has low rate limits, for example? Is the unified API company introducing new rate limits that impact integration design?
  6. System discrepancies in required fields and available methods - Systems may have different required fields for different methods and resources. Understand how the unified API is handling these and whether you are responsible for consulting each system to understand their requirements and limitations (for example, one system allows updating contact information, while another does not.)
  7. Customer experience - Related to the points about missing, irreconcilable and opinionated data fields, how will the customer experience ultimately compare to a natively built integration? How will that UX impact customer satisfaction or usage?
  8. Updates - A unified API has to continually assess the APIs they are connecting to. Understand how quickly they update their model and what happens if a partner system introduces a significant divergence to other systems. Do they quickly incorporate additional webhooks or a new GraphQL API, for example, or will your customers have to wait to use that functionality? Do they have strong partnerships with all leading systems to get visibility into the API roadmap ahead of time?
  9. Versions - Examine how often the unified API releases a new version and how often they deprecate their API or parts of it.
  10. Churning off the unified API - Consider what happens if you churn off the unified API or it goes out of business. How repurposable will the code be that you invested in? Will you be able to reuse any of it to write new integrations directly to partner APIs?
  11. Developer satisfaction - Do your developers want to become experts in this unified API? There is widespread demand for developers who can build with the Salesforce or Quickbooks APIs, for example. This is a marketable skill, while working with this unified API may offer few future job opportunities if the unified API does not have a similarly large market size.
  12. Data storage and security - Find out whether the vendor is storing your customer’s data and credentials, and if so, for how long. Request a SOC 2 report if they have one. Remember that you are the customer of the unified API vendor, not your customers, and consider how actively your customers are or aren’t consenting to having their personal data and/or credentials stored by a third party.    

If you ask all these questions, and get satisfactory answers, unified API companies aimed at product integrations can be valuable in streamlining development. Ultimately, unified APIs are most likely to fulfill their value proposition when they tackle a limited set of use cases that are based on similar APIs in one vertical. It also helps if your customers’ integration needs are not diverse and do not heavily rely on the idiosyncrasies of each system.

Before selecting a vendor, scope out the integrations your customers need (and will need if you continue to grow) and assess how much coverage the unified API will be providing. If your developers are going to end up having to do significant work directly with the partner APIs anyway, it is likely not worth incurring the additional costs. 

If the unified API vendor meets the vast majority of your customers’ integration needs, however, they may be a smart choice for quick development.

Keep up with Pandium

We regularly create quality content on how to leverage tech partnerships and integrations to grow. Subscribe to our bi-monthly newsletter so you don’t miss any of it.
Keep up with Pandium by subscribing to our newsletter