Finding the best unified API in 2024
Picking the right unified API for your product is an important infrastructure decision. We hope this guide helps you make a thoughtful choice.
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:
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:
- The number of APIs & categories the unified API supports
- The depth of coverage in each category (data you can access & actions you can take)
- 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.
Number of APIs and categories the unified API supports
This one is highly dependent on your product, but the question is always the same:
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 a deeper HubSpot API integration 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:
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.
The three types of unified APIs
Most unified APIs can be summarized into one of three categories.
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 2,000 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!
Useful resources
How to build integrations you and your customers love
Should you build or buy product integrations?
