How to Choose a Unified API Provider

How to Choose a Unified API Provider

Choosing a unified API provider is easy. The parameters listed below will give you a good starting point for choosing a unified API provider.

Cost

You need to decide whether to buy or build. Addressing the buying vs. building question will take a whole post on its own. The jury is out though - buying is better in the long run if your core strength is not integrations.

That out of the way, the next thing you want to look at is the cost of the unified API solution now and as you scale in the future.

One of our mentors, Jayanth Mohana Krishna, said it just right:

"Most subscription-based SaaS tools tend to turn out expensive in the long run."

See if you can lock in a long-term deal with your unified API provider. This will make sure there are no surprises in the future and you are not suddenly forced to switch vendors on a fundamental part of your product offering.

Integrations/Connectors supported

It's always better to go with a unified provider that has a good roster of integrations/connectors. They should at least cover the top 5 solutions in each category because these are the integrations your customers are going to ask you for.

It'll also do good to get their thoughts on how frequently they add new integrations/connectors, how frequently they update their APIs to accommodate for changes in the underlying API, whether they support deprecated versions, and their integration roadmap (ideally they shouldn't have a roadmap). What's their assurance on turn around time for new integration/connector requests - 2 days, 7 days?

What's even better is the ability to add integrations on your own without having to depend on your unified API provider.

Documentation

It's important that your developers can find their way around easily instead of having to reach out to your unified API provider's support team or get on calls to figure things out (the irony).

Some unified API solutions like Truto are built to be intuitive from the ground up, so your dev team may not even have to refer to the docs. That said, it still helps to make sure the provider has robust documentation.

Operations supported

One of our customers saw a huge roster of integrations/connectors with one of our competitors, started a trial, and then things fell flat when they found out that all CRUD operations are not supported across most of their supported integrations/connectors. Most were read-only. Look for providers that support all CRUD operations across all endpoints that allow them.

Another extension of this is the number of endpoints supported - make sure that all the endpoints you need including those needed for edge cases are supported. What's sweeter is the ability for you to add endpoints on your own if needed.

Time to integrate the unified API solution

Imagine looking at using a unified API solution to fast-track integrations, and then staring at an integration timeline of 45 days to implement the unified API solution itself.

Look for implementation timelines—ahem, using timelines here doesn't feel apt. You should be able to hit the ground running in less than 30 minutes.

Longevity

You want to look for other customers that are using the product—how big are these customers, how long have they been using it, and what's their review of the platform.

You can also ask your unified API provider how long they have been in business and what their 1-, 2- and 3-year plans are.

Data storage

Get these questions addressed—Do they store the data on their servers? How frequently do their jobs run? Can you get data in real time if you want? How are the credentials stored?

Security

Your standard compliance checkpoints are here—SOC 2, ISO, GDPR, and CCPA. At least look for a letter of engagement for the frameworks under process.

Custom API integrations

Custom API integrations come in when one of your customers asks for integration with that obscure app nobody has heard of. It's important for you and your customer nonetheless. You still need to support it. Your sales team is probably behind you on it. It's for a big deal you don't want to lose.

Look for unified API providers that can build custom API integrations for you or give you the ability to do that. Otherwise, you'll end up spending time writing custom code for each of these integrations, with developer hours wasted on not just building the integrations but on maintaining them too.

Relevant:

Standards

Scalability

Some solutions from unified API providers work great while you're a small team with fewer customers. As soon as the number of jobs you run increases, you start to see cracks. This is going to affect your customers. Stale data, broken links, and broken workflows are problems you don't want as a growing company. Ensure that you ask questions about the unified API provider's tech stack and assess it for scalability.

Support

When shit hits the fan, you need to be able to get on the phone with someone. You need someone who's proactive. You need someone who's reachable by email. You need someone who's reachable by chat. You need someone who's there 24x7. Ensure that you have enough support behind you for that one day when things suddenly break. Ask for SLGs.

Here's a summary of the parameters:

• Cost
• Integrations/Connectors supported
• Operations supported
• Time to integrate the unified API solution
• Longevity
• Data storage
• Security
• Custom API integrations
• Scalability
• Support

Nice-to-haves in a unified API provider

Ability to add your own APIs

Cut to the chase when you want to add your own APIs instead of raising a request and waiting on your unified API provider to deliver on their roadmap.

Declarative

Simply tell the code what you want it to do without having to tell it how to do it. The power this will give your developers cannot be overstated.

Access to raw data

Your unified API provider does an amazing job abstracting data from various API sources. Makes it stupidly simple. That's great. No matter how well they do their job, you'll have to deal with edge cases from time to time. Make sure you are able to access the raw data when needed to deal with those.

Support for all CRUD operations

Most times, unified API providers get the read, and delete out of the way. They are the easiest to do. Make sure you also have support for create and update on all endpoints that allow them.

Sandbox accounts

Do they provide sandbox accounts for you to play around with to understand the product? Not just the sandbox account of their product but sandbox accounts for the integrations you are interested in.

Using your OAuth app instead of theirs

Imagine asking your users if "a third-party provider" wants access to their data vs. "your company name" wants access to their data.

Analytics

This will help you measure which clients are using the integrations effectively and which aren't. An important metric to track for your Customer Success team.

Here's a summary of the nice-to-haves:

• Declarative
• Access to raw data
• Support for all CRUD operations
• Sandbox accounts
• Using your OAuth app instead of theirs
• Analytics

---

Think we may have missed something here? We would love to hear from you and get your thoughts. Please write to us at [e-mail]

Build +200 native integrations

Using Truto's Unified API for CRM, Unified API for ATS, Unified API for HRIS, Unified API for Accounting, and 26 other categories
Get started free