Picking the right unified API for your product is an important infrastructure decision. We hope this guide helps you make a thoughtful choice.
August 23, 2023
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:
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:
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.
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?
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.
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
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
Depth of use-cases covered
Unlimited (users can customize and extend integrations themselves)
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