The comprehensive guide to SaaS integration platforms

Over the past few years, companies have come to market with solutions to this problem, promising to streamline the effort required to build and maintain native integrations. These solutions fall into a few categories:

1. Embedded iPaaS

2. Embedded workflow automation tools

3. Unified APIs

4. Embedded ETL platforms

Now, just to give a quick overview of the different solution categories.

First, we’ll clarify the difference between Embedded Workflow Automation tools and Embedded iPaaS, given that both solution types provide visual workflow builders.

Embedded iPaaS: These platforms are focused on the B2B use case - helping engineering teams at B2B SaaS companies accelerate the development native integrations into their product, and provide visual integration logic builders.

Embedded workflow automation: These platforms are B2C focused and designed for non-technical end-users/system integrators to build automations within their own tech stacks, but have released secondary ‘embedded’ products to try and tackle the native integration use case.

Unified API: These are APIs that generalize multiple underlying APIs within a specific category of applications (such as CRMs), so that in theory, you can define the business logic once and have it scale across multiple integrations. We wrote about these products and their limitations here.

Embedded ETL: Similar to embedded workflow automation tools, these platforms are primarily focused on helping internal teams build data pipelines from their various tools into a data warehouse. Some of these companies have started to release secondary ‘embedded’ solutions. You’ll often see them call the embedded product ‘Powered by X’.

With all these choices, making a decision on which platform to partner with can be confusing. So let’s walk through the key considerations that you should think through.

Decision framework:

For a comprehensive evaluation, here are the factors that need to be considered:

1. Security - what requirements do your customers have around their data?

2. Integration use cases - what use cases do your customers require the integration to achieve?

3. End-user experience - how do you want users to interact with the integration?

4. Developer experience - how well does the platform fit into your developers' workflows?

5. Integration Infrastructure - how will you handle executing high volume/concurrent requests

6. Bespoke integrations - Do certain customers require custom/bespoke integrations features

Let's walk through each of these considerations in more detail, and we'll provide a generalized decision framework at the end.

Security

We’re starting with security because if a platform doesn’t meet your company and your customers’ security requirements, then there is no point evaluating it further.

That said, the leading providers in each of the categories generally check the marks for both SOC 2 and GDPR.

The only exception here is if your customers have even more stringent security requirements around PII that require you to host all of their data in your own infrastructure.

If that’s the case, embedded iPaaS is the only category with a solution that fits the bill.

More specifically, Paragon (embedded iPaaS) is the only solution across all categories that provides a self-hosted deployment (on-premise) option. All other solutions, across all categories, are cloud-only which means your customers’ data and credentials will be processed and stored in their infrastructure.

Integration Use Cases

Assuming on-prem isn’t a requirement, this brings us to the next, most critical criteria - feature flexibility/use case compatibility.

When picking a platform for your native integration strategy, you need to know that it can support all the possible integrations and use cases that your customers request. As you grow, prospects and customers will continue to ask for new integrations, or additional features and iterations for existing integrations.

You do not want to find yourself in a situation where one or two years down the road, the integration platform you’ve chosen can’t accommodate an integration feature that’s on the roadmap (or without many workarounds).

So let’s take a look at each solutions category and their capabilities to support a breadth of use cases.

Unified APIs

While unified APIs allow you to define the business logic for a category of integrations once and have it scale across all its supported integrations, you are limited to a set of endpoints that can be generalized across all its underlying APIs.

This strips away the possibility of building integrations that tap into the unique functionality of any specific provider.

Here are a few examples to illustrate:

1. While HubSpot only has a single Contact object, Salesforce has both Lead and Contact objects. Within a unified model, your integration needs to completely ignore one of the two Salesforce objects, which is not acceptable for many Salesforce customers.

2. One applicant tracking system (ATS) may use a number scale from 1-10 to grade a candidate, whereas another may use qualitative measures such as ‘weak candidate’ and ‘strong candidate’. A unified API provider would either prevent the usage of these fields, or make their own decision on how the 2 scales should map to each other.

Ultimately, there is no way to build a single set of business logic that can work with multiple integrations unless you give up all of the integration-specific functionality.

Additionally, you will be limited to building integrations that are supported by the platform’s unified APIs - anything outside of that will need to be built in-house.

For example, a platform like Merge may provide unified APIs for CRMs or HRIS, but if you want to build a Slack integration, you’ll have to build it in-house.

So unless you know for certain that you will never need to access integrations or endpoints outside of their unified model (aka very generic use cases), there’s a high likelihood you’ll run into limitations down the road when trying to accommodate integration specific use cases, which forces rewrites.

✅ Supports very generic use cases such as sync Contacts/Tasks

❌ Limited by integrations that fit within their unified API categories

❌ Extremely limited endpoint coverage 

❌ Lack of webhook/custom triggers support

These are fundamental tradeoffs that come with this product class (in order to deliver the 1:M efficiencies), and we’ve seen a huge inflow of companies shift away from unified APIs in 2023 due to this exact reason.

Embedded iPaaS

Within this category of solutions, there is a range when it comes to the level of extensibility the platform provides. Certain providers optimize for the low-code experience (which comes with more limitations as a tradeoff), whereas others, like Paragon, focus on providing both abstractions as well as control and extensibility to developers.

For example, while we provide triggers and actions for the most common use cases, developers can still access the 3rd party app’s underlying API, write custom Javascript functions, and even build custom integrations with any 3rd party application, even if it isn’t in our catalog.

✅ Supports most integrations (either by request or through a custom integration builder)

✅ Supports integration specific webhook/triggers (real-time/scheduler)

✅ Most solutions provide access to the full underlying 3rd party API

✅ Supports complex business logic

Workflow automation tools with embedded offerings

These are nearly equivalent to the low-code optimized Embedded iPaaS solutions from a use case compatibility perspective.

The only caveat is that their focus is on the business user use case, which means workarounds are often required to achieve use cases that aren’t supported out of the box.

✅ Supports most integrations (generally by request)

✅ Supports integration specific webhook/triggers (real-time/scheduler)

✅ Supports complex business logic

✅ Most solutions enable you to make http requests to 3rd party APIs directly

Embedded ETL

ETL platforms are used to consolidate data from multiple data sources, generally through integration connectors. As a result, embedded ETL platforms are only able to handle scheduler based sync use cases.

They do not have the ability to implement logic based operations (if this happens, do that), nor sync in real time.

Here are a few examples of extremely simple integration use cases that they cannot support.

1. Trigger a Slack notification whenever a Contact is created within your app

2. Check if a Contact’s email domain in Salesforce matches a Company’s domain in your application

3. Trigger an automated confirmation email to send from your users’ Gmail account when a recipient signs a contract

✅ Supports mass updates of single object types (ie. pull in all changes to Contacts, or pull in all updates to Tasks)

❌ Cannot sync in real time - limited to schedulers (ie. sync every hour)

❌ Cannot support unique business logic (if this then that)

❌ Very limited support of webhook/triggers

Checklist

• Access to every endpoint

• Ability to build custom integrations

• Ability to build different types of use cases (sync, automation)

End-user Experience

The previous section should have narrowed down the solution categories that can support all of your product’s current and future integration requirements.

Next is the integration experience that these platforms enable you to provide to your customers. We break down this category into two buckets within the context of integration platforms.

1. White-labeling

2. Configurability

White-labeling

The benefit of providing native integrations is that the end-user experience feels like a seamless part of your product - just like every other feature you have.

When a customer buys your product, they are evaluating you as their vendor. They expect that you have control over the reliability of the product, and that their data is securely handled with you (upon a security evaluation).

However, if the integration platform you use doesn’t provide a truly white-labeled experience, that can immediately raise concerns in your prospects’ or customers’ minds.

‘How come I am authenticating via a 3rd party service that I was not aware of.”

“Do they have access to my credentials and data…?”

This can lead your prospects towards evaluating the reliability and security of the underlying integration platform, even if you had already done the due diligence yourself.

As a result, you should always ensure that the solution you adopt is fully white-labeled so that you avoid the unnecessary friction in the sales process/product onboarding process.

Configurability

What’s arguably more important is how configurable the integrations can be. But what is the right amount of configurability? It’s a question that product teams need to think through carefully.

No configuration

On one end of the spectrum, no configurability is provided. You fully define the behavior and business logic of the integration, and users have to accept the opinionated decisions you make.

Two simple examples:

1. A Slack integration that forces the creation of a new channel called ‘ACME’ and sends notifications there (even if the users may want notifications to go to an existing channel)

2. A Salesforce integration that syncs Contacts without a way for users to edit the way the fields are mapped (no custom fields supported)

This is not ideal, as it does not accommodate users defining their own settings for the integration. With certain implementations, this can prevent your users from using the integration altogether.

Boundless configuration

On the other end of the spectrum, you could give your users the ability to fully customize and make changes to the business logic of the integration by surfacing the workflow builder (which certain solutions provide).

While this may seem appealing at first, as soon as your customers make their first edit, all the QA that your team has done is rendered useless. These changes introduce risk through untested logic, which can introduce breaking changes and errors.

This quickly turns into a support nightmare, and can also hurt your customers' perception of your product as issues (that they caused) may be left unresolved for days.

Optimal configurability

The perfect balance falls somewhere in between - you should define the business logic behind the integration, and provide your users configurability within boundaries that you set.

For example, using the earlier examples, you can provide user settings such as ‘Select the Slack channel for notifications’, or dynamic field mapping that enables users to define how the fields and objects in your application should map to with Salesforce.

Again, let’s walk through the end-user experience that you can provide with each of the solution categories.