by CData Software | March 25, 2024

Product Integration Strategy: Build vs. Buy SaaS Integrations

Enterprises and the solutions providers who serve them face a daunting new reality — there are too many applications, and there’s too much data scattered across all those apps.

The average enterprise uses more than 150 SaaS solutions. And according to G2 Research, 82% of software buyers expect any new solution they buy to connect with the tools they already have.

Bottom line, adding sufficient native integrations to your solution is more important than ever. But delivering 150+ API integrations is too much for most development teams for a variety of reasons:

• Time-to-market: It takes six months to build one integration, and two years for complex data sources
• Variance kills scalability: Technical variance across APIs means every integration is a custom job
• Endless maintenance: Building integrations is the easy part; the bulk of the work is maintenance
• Team misalignment: Building integrations at scale takes a large, specialized team
• Cost: Custom integration processes quickly stretch into the millions per year as you scale integrations

For most ISVs, connectors are not your core product; they’re just another required box to check on your roadmap. Embedded CData Connectors are a scalable solution for native integrations trusted by data ISVs, from startups to the top technology companies in the world — Google, Salesforce, Tibco, Collibra, and more.

Ship in weeks or add years to your backlog?

The typical product team can build one performant connector in about 6 months, and the timeline is more like two years to build full connectivity across all the tables and fields that matter for complex enterprise data sources, such as Workday or NetSuite.

If you intend to build your own connectors, that six- to 24-month timeline maps to several steps:

• Proposal: Plan and scope your integration with key features and functionality
• Implementation: Create original code for each integration (you can’t reuse code across APIs)
• Code design review: Conduct peer and manager reviews of your code
• QA review: Run code and queries through automated and human Quality Assurance testing
• Help review: Create documentation for your integration so your customers can use it

With an off-the-shelf connectivity solution, your connectivity provider has already handled each of these steps, and you can deploy a connector in weeks. Scale that across the dozens or hundreds of integrations your customers demand, and you can see how you’ll shave years off your backlog by purchasing a connectivity solution.

6 Ways API variance makes integrations unscalable

The central challenge of building product integrations is the lack of scalability. Every API is different, so the integration you build to one API doesn’t work for others for a variety of reasons.

1. API standards aren’t standard: REST standards vary wildly even for ‘modern’ APIs, while many major database and SaaS APIs still use older SOAP standards with even less commonality.
2. Data models vary: APIs use different data models to expose data. For example, one API may expose a Purchase Order as one big file where individual line items (metadata) are inaccessible, while others may expose each individual line item within that PO as a unique object or even field. You have to modify and customize your API queries to account for these variances and surface that data in a way that makes sense to users in your platform.
3. Metadata access: Users of data-centric solutions need metadata for an integration to be useful. But if the APIs you query don’t surface that data, you’ll have to spend the time breaking flattened documents into individual pieces within your solutions. Now imagine doing this for thousands of field types across hundreds of APIs.
4. Undocumented APIs: API documentation is often minimal or even nonexistent, as many enterprise solutions were not built with modern third-party integrations in mind. That will leave you spending countless hours combing through docs to find crumbs or trial-and-error testing third-party APIs on your own. Yikes.
5. Developer access: To code an integration and test out your queries, you’ll first need access to each API. But many solutions providers charge developers a pretty penny to access their APIs — if they offer developer sandbox credentials at all. In some cases, you’ll have to purchase a $10k+ enterprise license to their solution.
6. Authentication challenges & token expiry: Many integrations require you to set up OAuth authentication, but OAuth isn’t really a protocol; it’s a skeleton of a protocol and app developers use wildly varying implementations of it. You’ll also have to refresh tokens at different rates — some never expire, others are good for a few days, and some depend on how users configure them. If at any point a token is not authorized, your customer’s integration will break.

We cover everything you need to know about OAuth in our comprehensive guide to OAuth 2.0.

Integration is endless maintenance

Building your product integrations is the easy part. The hard part is making sure they work, continuously, for every customer. Integration never ends, and maintenance makes up the bulk of the work over time.

APIs change all the time

One major challenge is that solution providers regularly update their APIs. We’ve observed that every API receives a major update at least every two years, while the best supported APIs change significantly every 3-6 months.

Yes, one change every few months seems like no big deal, but multiply that by 100 integrations and you quickly reach a point of overwhelm. And you simply cannot ignore API changes, because they will disrupt your customers.

• Breaking changes: Changes to the way data is exposed from the underlying API can and absolutely will break your integrations if you don’t stay on top of them.
• Security updates: The most common changes are security updates. Fail to stay on top of these and you’ll leave your connections vulnerable to security breaches.
• New features & functionality: Not every change is a breaking change, but your customers will ask you to support the full functionality of third-party APIs.

You have to support & debug third-party APIs

To debug and fix errors, you must be able to replicate and understand them. But errors stemming from third party APIs are notoriously cryptic. Sometimes, you won’t even receive an error. Other times, you’ll be dealing with user errors. You’ll need efficient ways to determine when there are genuine problems to fix and when you’re troubleshooting end user configurations or authentication errors.

You’ll need to build thorough documentation

Your support engineers likely are unfamiliar with third-party application APIs, so to effectively support issues associated with those APIs, you’ll need to create thorough internal documentation and runbooks as you go. This is a time-consuming and resource intensive process.

It’s inefficient to hire your own integrations team

Most product teams build their first few integrations themselves but quickly reach an inflection point where the decision comes down to finding an off-the-shelf solution or hiring a dedicated integrations development team. Given the variance of APIs and the ongoing support requirements, you can see why a team is needed. But is it wise to build one, and what are the costs?

How many integration developers do you need?

We have observed in our years of building and maintaining API integrations and working with SaaS solutions providers that you can plan to staff (at minimum) 1-2 developers for every 5-7 APIs you plan to support. That’s a general rule of thumb. For complex enterprise APIs, you may be surprised to learn it’ll take one developer for each integration. And then you have to account for redundancy. You’ll need to cross-train members of your team and ensure you have coverage across APIs in the event you lose the one developer who is an expert in NetSuite’s API, for example.

For example, one of our major OEM partners who embeds CData Connectors into their solutions calculated they would need 120 full-time developers to deliver the 300+ connectors they embedded with CData.

Calculating the cost

If you can manage to staff your development team with developers in India, you’re looking at an average cost in the tens of thousands per integration. And the unit costs don’t come down as you add more integrations due to the variance and maintenance inherit in API integrations. Even ignoring the initial hurdles and setup costs of spinning up an offshore team if you don’t already have one, the costs will quickly skyrocket into the millions as you scale your integrations.

API variance creates expertise gaps and hiring challenges

But there’s another challenge. Let’s run a thought experiment and say the math works out and you do opt to build all your own integrations. The real problem you’ll face is the difficulty in hiring and training that team. Due to the many variables in API development, building integrations requires specialized programming expertise across each API. You’ll need an expert or two for HubSpot, NetSuite, Workday — maybe hundreds of others. People with that expertise don’t grow on trees, so you’ll end up either spending time training them up or overpaying.

Does building an integrations team align to your vision?

If you can staff that team, and that’s a big if, does it make sense? Integration developers bring highly specialized domain expertise to solve a niche problem tied to other organization’s solutions. But the most successful product teams cultivate exactly the opposite skills. They’re built to solve bigger problems and deliver differentiating capabilities tied to their core value. As the head of product for one of our partners at one of the world’s top technology companies put it:

“We don’t hire people who know HubSpot’s API, we hire people who can solve very complex problems and write very complex code. We want to look at next-gen products. The people we hire are thinking about solving really complex problems.”

- Head of Product; Top Global Cloud Solutions Provider

Why CData for embedded connectivity?

While bringing integrations into your solution provides value to your customers, it is not the central value proposition of most solutions. Your development team has precious time they must spend on building your core differentiators, especially because both you and your competitors can procure off-the-shelf connectivity.

At CData, integration is our core business.

Building and maintaining integrations is not a one-off project, especially for data-driven solutions. We have data connectivity down to a science, saving your team countless hours so they can focus on building your product.

Connect to every API the same way for scalable integration

Our SQL connectors standardize API endpoints inside a standard SQL wrapper. You can connect to all 300+ APIs we support using SQL. Through a SQL abstraction layer, CData Connectors make every single API look the same to your product, so you can connect to them all the same way.

Proven technology

Our connectors are battle-tested and proven. More than 150 data ISVs, including the biggest names in technology like Google, Salesforce, Palantir, and Collibra have embedded CData Connectors into 2,000+ applications. Our connectors power 2.7 billion queries and retrieve over 1.7 trillion records per month.

See our customers

We support third party APIs

We have thorough documentation for every single connector and product we offer. We also provide direct support to you and your customers. And we deliver continuous maintenance and support, protecting you against ever-changing API endpoints and helping troubleshoot errors.

Security you can trust

CData is SOC-2 Certified. This is a highly rigorous certification process performed by qualified third-party auditors. We also run continuous penetration testing and security checks with Checkmarx.

Learn more about our security