Finding the best unified API in 2023

Picking the right unified API for your product is an important infrastructure decision. We hope this guide helps you make a thoughtful choice.

Robin Guldener
August 23, 2023
8
min read

The promise of unified APIs is as simple as it is magical: A single API to access a lot of different APIs. Integrate once and get integrations with dozens of different APIs, without having to know these APIs in detail.

When a SaaS product decides to build integrations with a unified API, we see they often have three goals in mind:

Build integrations fast
They want to ship integrations fast and without weeks of engineering work.

Integrate once, get many different integrations
The promise of a unified API is that you integrate with it once and gain support for many different integrations. This makes integrations non-linear: You immediately support more APIs, which wins more deals, and avoid having to build integrations one by one.

Reduce maintenance for integrations
Because the unified API maintains the integrations with the underlying APIs, you reduce the maintenance burden for your engineering team. Now you only have to maintain a single integration with a single, well-built API.

To achieve these goals it is important you pick the best unified API for your product and use-case.

How do you decide which unified API is right for your SaaS? Why does this choice matter?

Let’s dive in!

Why choosing the right unified API matters

The right unified API should help you build all your product integrations.

Integrations are a key purchasing consideration for prospects: You need to offer your customers the integrations they need, or you lose the deal.

This means that as an engineering team, you often don’t have a choice whether you build a certain integration or not.

The question is just how do you build it:

  • In-house from scratch, which is a lot of work to build and later on maintain.
  • Or do you buy a pre-built solution, like a unified API, that helps you build integrations faster and with less maintenance.

To truly deliver on its promise, a unified API needs to enable two things:

  • It needs to cover all of the APIs you want to integrate with
    • So you never have to build in-house from scratch
  • It should not limit the kind of integrations or use-cases you can build
    • So you can cover all the integrations your customers need

Otherwise you might find that the unified API only helps you build a small part of your integrations.

For the rest you still have to build integrations in-house from scratch.

This means you also have to build and maintain your own infrastructure for integrations again (scheduling, retries, monitoring, rate-limit handling, API specific code), whilst working against the limitations of a unified API that you even pay for.

How to find the best unified API for your product integrations

There are three criteria you should evaluate for unified APIs:

  1. The number of APIs & categories the unified API supports
  2. The depth of coverage in each category (data you can access & actions you can take)
  3. The extensibility: If the unified API doesn’t cover your use case, how much do you have to build yourself?

Let’s briefly look at each of them.

Unified APIs give you a single API to access many different integrations

Number of APIs and categories the unified API supports

This one is highly dependent on your product, but the question is always the same:

  • Does it cover the categories you think you want to integrate with?
  • Does it cover the APIs you hear from your customers?
  • For APIs not covered: Do you have any guarantee that they can and will be supported?
    • All providers will tell you they can add the ones you miss. But it could take months, you may need to pay more or it might never become a priority for them.

With unified APIs, a one-stop shop is best.

After all, you are looking to reduce the number of APIs and interfaces you need to understand. If you have a different unified API for every category, or even just 2, you again have to work with different patterns, different monitoring & management portals, different billing etc.

Usually you also get a better deal with the unified API if you have higher volume with them, so multiple unified APIs are likely to be more costly than one.

Note though that the number of APIs alone is not enough, the depth of coverage also matters.

Depth of coverage: Is your use-case covered by the unified API?

Just ticking the box for an API is not good enough, you also need to be sure that the unified API covers your specific use-case.

Some examples:

  • Does it let you continuously sync contacts/leads/X from CRMs/the APIs you need?
  • What about custom fields?
  • And comments on notes on Opportunities/deals?
  • Custom objects?
  • Can you update all the records in the external system you need?
  • Is the data fresh enough/real-time?
  • Does it handle deleted objects? (Not all do!)

The specific questions to ask will depend on your product and the kind of integration you are looking to build with the external APIs.

Today and in the future
When checking coverage you should also think about the future: What are likely use-cases you will need in 6-12 months?

Integrations often start simple, but once customers get used to them they start to demand deeper and deeper interactions with the external system. Can the unified API cover these as well for you?

If not, you will need to think about extensibility.

The lowest common denominator problem: Why extensibility matters

Because unified APIs unify a number of different APIs into a single interface, they fundamentally limit what you can access and do in the source APIs.

This is something all unified APIs share: It is inherent to the concept of unification.

This is a problem, because you are bound to run into the limitations of unified APIs (sooner rather than later).

For instance Salesforce and HubSpot are both very popular CRMs. They share some common features, but each also has unique things the other does not offer.

If a lot of your customers use HubSpot, they are likely to demand deeper integrations with some of the features Salesforce does not have.

These features are unlikely to be covered by the unified API, as they are specific to HubSpot.

Because of this, unified APIs only deliver on their promise if you can customize them.

Otherwise, you need to build around them, which is even more painful than building from scratch:

  • You need to build your own infrastructure again for pagination, retries, caching, change detection, scheduling, monitoring etc.
  • You need to understand the external API and its response in detail
  • You need to understand the unified API in detail
  • You need to discover and work around the quirks of the source API and the unified API

To avoid this, the unified API should let you customize and build custom integrations on their platform and infrastructure.

This way you benefit from all the pre-built parts that the unified API already has (infrastructure, (O)Auth, rate-limit handling, pagination, data management, monitoring etc.) and build faster and with less maintenance.

We recommend you look out for these:

  • Custom API requests: Does the unified API let you make custom API requests that still handle rate-limiting, retries and pagination for you?
  • Custom incoming webhooks: Can you leverage the unified API’s infrastructure for incoming webhooks that you need?
    • This is a big one to build internally, as it requires queuing, rate-limit handling, data caching, de-duplication, scaling, monitoring etc.
  • Custom data syncs: Can you leverage the unified API’s infrastructure to continuously sync data from the external API?
    • This is a big one to build internally, as it requires scheduling, retries, data caching, de-duplication, scaling, monitoring etc.
  • Custom data schema: Can you extend the unified API’s schema to include additional fields you want to sync from the external API?
    • If not you will likely have to build your own syncs or run additional API requests for every record you fetch
  • Add new APIs: Can you run all integrations for all APIs on the same platform?
    • Otherwise you will have to have duplicate infrastructure and data models for different integrations

Another thing to keep in mind is independence: Can you make these changes without having to wait on the provider of the unified API?

If you need support for an additional API that isn’t in the top 100 APIs globally it could take months for the unified API provider to add them (if they do at all).

Data schema changes are even trickier for closed unified APIs: They have a single data model for all customers. Changing the mapping of a field or adding your own fields to them is just not feasible as it would cause migrations for all their other customers.

Open unified APIs vs. closed unified APIs

The three types of unified APIs

Most unified APIs can be summarized into one of three categories.

  Niche unified APIs Closed unified APIs Open unified APIs
Description Focus on a specific niche or vertical, e.g. warehouse systems, Point of Sales (PoS) software etc. Cover many different categories, closed platform where one company develops all integrations Similar to closed unified APIs, but let you extend and customize integrations on the platform
Number of categories & APIs covered Few Few Many
Depth of use-cases covered Depends Depends Unlimited (users can customize and extend integrations themselves)
Extensibility None to low Low: Cannot leverage pre-built infrastructure for custom extensions or integrations High: Build custom integrations on the same infrastructure or extend existing integrations
Examples Terra, Smartcar Merge.dev, Apideck Nango

Conclusion: The right unified API can accelerate your integrations roadmap

We hope this article has helped you find the right unified API for your use case and product.

If you are still unsure which approach is the best for you, check the Nango Slack community with more than 800 developers and product managers building integrations for B2B SaaS products.

They might have additional guidance and recommendations for you based on their own experience.

See you there!

Robin Guldener
Co-Founder & CEO

Originally an engineer himself Robin has worked on product integrations for 6+ years. Today he is a co-founder at Nango.

Ready to get started?

Try Nango live in 3 minutes.