Integration Solutions for B2B SaaS: A Head-to-Head

There’s been a major transition in the way SaaS companies are developing their products’ native integrations. Most product and engineering leaders acknowledge two facts:

1. Integrations are a must-have to compete in today's market (customers expect interoperability)

2. Shipping and maintaining dozens of integrations is incredibly costly given the engineering effort required

Companies like HubSpot, Slack and Atlassian were ahead of the wave - they invested tens of millions of dollars in engineering to build integrations with other applications which ultimately led to their dominance in the market (first mover’s advantage). But today, integrations are table stakes, and earlier/mid stage companies can't afford to build entire teams of integration engineers just to build parity with larger competitors.

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.

Unified APIs

White-labeling

White-labeling with Unified APIs is solution specific. While some provide a white-labeled authentication and configuration experience in their higher tiers, others force users to go through a branded auth page.

Configurability

This is where unified APIs fall short, once again.

Given the nature of the unified data models, there is a lot of built in rigidity with the integration and the logic behind it. Some platforms don’t offer any field mapping or integration configuration options, whereas some offer limited field mapping capabilities (no custom object/field support). Here’s just one example where a unified API customer expressed feedback on the lack of configuration options. The provider’s name is redacted here out of respect.

“The biggest challenge that we encounter is the rigidity of the choices made by the normalization for the various {Unified API provider} objects which we draw down - it is not uncommon that we have customers who want to use field X rather than field Y.”

✅ Most are white-labeled through an embedded UI

⚠️ Limited configuration options for end-users

❌ No custom object/field mapping support

Embedded iPaaS

White-labeling

Every embedded iPaaS solution provides a white-labeled end-user UI that you can toggle branding on or off, given that they were designed specifically for the use case. 

Beyond that, there are usually a few options for how your customers will interact with the integrations.

1. Pre-built integration marketplace (iFrame/3rd party URL)

2. Embeddable UI components for each integration

Additionally, certain platforms provide more custom options such as a custom marketplace and/or headless.

Here you can see how one of our customers, Harbour, built a fully custom UI interface on top of the Paragon SDK.

Configurability

Embedded iPaaS solutions enable you to provide your users configurable experiences - all mature solutions in this space offer support for user-defined settings and user-defined field mappings.

The primary differences that you’ll see between different providers in the space is their ability to support custom/dynamic field mapping and/or pre-built field mapping UIs.

✅ All solutions have white-labeling capabilities, often with multiple embed options (marketplace, headless, etc.)

✅ Very configurable - all solutions support user-defined settings and field mapping

⚠️ Not all provide dynamic/custom field mapping

Embedded Workflow Automation Platforms

White-labeling

This is where embedded workflow automation platforms like Tray and Workato fall short. Given that the core focus of these companies is to serve end-users of integrations stringing together their own tools, there are inherent limitations with how native they can be.

Some do not offer any white-labeling at all, whereas others try to offer workarounds to achieve semi-white-labeling outcomes. The inevitable giveaway here is that the authentication is through the embedded workflow automation platform’s app, not your own.

Here’s an example with Tray Embedded, where the end-user needs to go through Tray’s authentication for Outreach (the integration).

In a more extreme example, Workato Embedded requires you to iFrame an entire Workato console within your application.

Configuration

Configuration wise, the solutions in this category are relatively feature complete. You can provide your customers custom/dynamic field mapping and user-defined settings.

Additionally, given that certain solutions require you to iFrame their entire product, your customers may have access to the workflow editor behind the integrations.

The risk is as we outlined earlier - there are no guardrails that you can set in place to prevent your users from breaking the integrations you’ve built, which works against the whole value proposition of providing seamless native integrations in the first place.

❌ Not white-labeled

✅ Very configurable - all solutions support user-defined settings and field mapping

⚠️ Some provide embedded workflow editors, which can introduce risk

Embedded ETL

White-labeling

Embedded ETL platforms are very similar to embedded workflow automation tools in this aspect. Given their core focus on internal ETL use cases, their embedded solutions are not white-labeled, and with some providers, require your users to go into their platform for configuration and authentication.

Configuration

You can provide your users configurability within the bounds of the ETL use case. This means that your users will be able to map your application’s schema to the 3rd party application, but again, any event-driven integrations are not possible.

So while they may also have embedded workflow builders, these ‘workflows’ are meant purely for building data pipelines that enable sync-only use cases.

❌ Not white-labeled

✅ Supports end-user defined schema mapping

⚠️ Some provide embedded data pipeline editors, which can introduce risk

End-user experience checklist

• Solution needs to be fully white-labeled

• Does it provide configurability without introducing maintenance risk
  
  

Developer Experience

If you’ve made it this far, it means that more than one of the solution categories meet your use cases and end-user experience requirements.

That’s a great starting point, but now we need to get into the actual usability of these platforms from your team’s perspective, which comes down to the developer experience.

To draw a comparison - your company is prioritizing native integrations because you don’t want to build a product that provides unique value but is completely disjointed from the rest of your users’ workflows (leads to low usage and unrealized value).

That same logic applies to picking an integration platform for your team. You need to ensure that the product is intuitive to use, fits within their existing software development workflows, and solves problems in the way that they’d expect it to.

If not, you may find your team wanting to rebuild the integrations on a different platform. We’ve seen this happen many times where companies have come to us to rebuild integrations that they had already built through another platform (usually an embedded workflow automation platform or unified API).

To simplify, we’ll boil down developer experience into a few buckets:

1. Implementation experience

2. Building the integration logic

3. Resiliency

4. Workarounds required

5. Programmatically managing users

6. Monitoring & observability

7. Release management
   
   

Let’s see how this manifests across the different solution categories.

Unified APIs

Unified APIs are just that - APIs. With the exception of providing an authentication layer, building with unified APIs is not very different from regular development.

On the one hand, this gives them the edge of familiarity, as developers work with APIs all the time, and the integration logic will fall within their own code base/infrastructure. However, that’s about it.

Implementation experience

Unified APIs provide SDKs so that you can embed the authentication experience for your users within your application.

Building the integration logic

Working with a unified API is not that different from making POST/GET requests to any other API. The benefit here is that in theory, you can define the integration logic once and have it scale to multiple integrations instantly.

However, even ignoring the limited endpoint coverage these unified APIs provide, you may run into challenges translating customer requirements to fit the common model, as objects will be referenced differently.

For example, a customer may have requests about how they want your integration to handle Leads or Opportunities in Salesforce, but the unified API may reference these as Contacts and Deals.

That said, the rest of the experience for building out the business logic should be no different than regular software development, given that they’ll be writing the code in their existing codebase.

Workarounds required

This goes back to the earlier point about feature flexibility and use case compatibility. Certain unified APis provide workarounds that will enable you to make ‘passthrough’ requests to an integration’s underlying 3rd party API, but in every case, this requires a lot of custom development to achieve.

Additionally, when it comes to using the few webhooks that these unified API solutions provide, your team still needs to spin up its own webhook endpoints.

From what we’ve seen, the number of workarounds and additional development required to implement relatively simple use cases is by far the #1 reason that companies switch from unified APIs.

Programmatically managing users

Outside of the ability to generate new integration users (aka your customers) and store their integration states (ie. customer A has connected Salesforce and Slack, customer B has connected HubSpot and Teams), unified APIs don’t provide much in terms of user management.

There is no ability to programmatically enable/disable users at scale, nor is there the ability to limit the availability of specific integrations to select customers.

Monitoring & Observability

Logging is limited to viewing the success/failure of individual API requests made to the unified API, which isn’t very different from building in-house, and as such, the integrations will only be as observable as the quality of your team’s code.

Release Management

Given that the business logic for the integrations built with unified APIs live within your own code base, the integrations will be deployed as part of your product in line with your existing release management process.

✅ Easy to implement

⚠️ Flexible within the common model

❌ Requires many workarounds and custom development

❌ Does not provide user management features

⚠️ Very basic logging for individual requests

✅ Falls within your existing release management process

Developer-focused Embedded iPaaS

Implementation experience

Embedded iPaaS solutions can be implemented in your platform by installing their SDKs - typically through npm.

This shouldn’t take more than an hour, and will be relatively straightforward for any developer.

Building the integration logic

Unlike unified APIs, embedded iPaaS solutions provide a visual workflow builder that will enable your team to easily implement the desired business logic for any integration.

Triggers and webhooks

Workflows can be triggered either on a scheduler (every 30 minutes), or by an event. An event could be something that happens in your app, something that happens in the 3rd party app, or when your user enables a workflow.

Here’s an example of how triggers are configured in Paragon.

API abstractions

These solutions provide abstractions over their supported integrations’ APIs, which means your team won’t need to build towards, and also maintain references to, each 3rd party app’s API.

However, for deeper integration use cases where abstractions may not be available out of the box, it is still extremely easy to make requests to the underlying API.

Functions

One hesitation that many developers have when they hear the phrase ‘workflow builder’ is that they will be limited to the functionality provided by the solution.

That is not the case with embedded iPaaS solutions, as they provide the ability to write custom code via function steps. These even support the usage of JS libraries and npm modules, so there are really no limitations as to what your team can build.

Operators

Any other tooling you’ll need to implement the desired use case is generally available out of the box, from conditionals, fan outs (concurrent loops), and more.

Workarounds required

Given that your team will be using the workflow builder to implement logic vs. authoring the integrations in code, there will be some vendor-specific limitations in corner cases. However, we’ve seen the solutions in the category evolve quickly to address 

For example, in our case, pagination was initially only supported for out-of-the-box actions, but now Paragon supports pagination handling for any API request.

Programmatically managing users

User management is another advantage that certain embedded iPaaS provide over the other categories. They are designed specifically for multi-tenancy environments where each of your integrations are deployed to all of your customers’ instances, and this makes it easy to apply end-user specific settings and metadata, which can unlock further functionality such as:

• Gating integrations/workflows to specific user segments (for upsells/bespoke features)

• Programmatically managing user integration states via a Users API

• Creating task usage limits for specific user segments (again, for upsells)

This is one of the major advantages of using embedded iPaaS solutions, as the ‘end-user’ is a first class object, whereas embedded workflow automation tools do not have the same architecture. 

Monitoring & Observability

One of the benefits with the workflow construct is that it is highly observable and debuggable. Instead of relying on your developers’ ability to write clean and maintainable code (which is rarely the case because of tight timelines), the nature of having compartmentalized steps enforces best practices.

You’ll be able to see very clearly, at a very granular step level, all the inputs and outputs of a workflow.

Additionally, it strings together all the requests into a single view, from trigger all the way to the outcome, so you can easily see exactly what went wrong. This is a huge advantage over building in-house or using unified APIs especially when it comes to support, because otherwise your team needs to parse through pages of logs to figure out which request failed (but we’ll get into that later).

Within the context of monitoring, what differentiates embedded iPaaS and embedded workflow automation platforms are the developer-centric features.

The best developer focused embedded iPaaS will also provide features such as:

• Event destinations/alerts, which integrates with your developer’s existing monitoring tools like Datadog, Sentry etc.)

• Task history API (for tracking usage and performance)
  
  

Release management

The release management experience with these solutions, at this time, is largely isolated from the rest of your codebase.

While most solutions provide the ability to have multiple ‘projects’ (ie. one for dev, one for staging, and one for prod), there is no formal project promotion functionality between projects.

On one hand, this enables fixes and updates to be implemented quickly.

However, this also means that someone on your team can deploy an integration, or deploy updates to an existing integration, without going through developer → staging → production environments.

Currently this is de-risked via role based access controls (RBAC), where only admins can deploy integrations.

Quick plug: Paragon is about to release our Releases product in Q3, enabling developers to promote projects through different environments (dev/QA/production) in sync with their core product’s release schedule. Subscribe to our newsletter here to be notified when it is released!

✅ Easy to implement via the SDK

✅ Easy to build complex integration logic 

✅ Very few workarounds required, only in edge cases

✅ Solutions provide robust user management features

✅ Robust monitoring suite

⚠️ Slightly disjointed from existing release management process

Workflow automation tools with embedded offerings

Without a doubt, the products that provide embedded as a secondary offering provide the worst developer experience for building native integrations.

This is because they are handcuffed by their core focus on low-code automation for non-technical users, on an entirely different use case (internal workflow automation).

Implementation experience

These platforms don’t provide SDKs, which is the first sign that they weren’t designed for the native integration use case.

You would need to create a new proxy instance of the workflow automation platform for every single one of your users, and build workaround logic and custom code to handle the authentication between your application and the workflow automation solution.

Building the integration logic

This aspect is relatively similar to the developer-oriented embedded iPaaS solutions, so we won’t repeat the same components again.

There are some nuances here, such as the fact that workflows can only be triggered via http requests, vs. app events through the SDK, but the overall workflow builder experience is quite solution dependent.

Workarounds required

Beyond the challenges required just to set up auth, there are many cases where workarounds are required due to the non-embedded core product.

Here’s an insight, though vague, that customers who have churned from Tray have shared.

“We switched from Tray to Paragon because of how inflexible Tray’s embedded product is - with the amount of time we invested into Tray, we could have built the integration ourselves. This was a big setback for us.” - Mav (conversational AI SaaS)

It’s important to go through a rigorous trial with these platforms, as many of these blockers don’t surface themselves in a surface-level proof of concept.

Programmatically managing users

This is virtually non-existent when it comes to working with embedded workflow automation platforms, because end-users are interacting with individual instances of the 3rd party platform. Any modifications you need to make to end-users’ integration states must be done manually via their dashboard, which is not scalable.

Monitoring & Observability

From a debugging and observability perspective, these platforms provide the same benefits as embedded iPaaS platforms due to the workflow construct, and the major players do provide log streaming now, putting them at par with embedded iPaaS solutions.

However, most do not provide APIs to pull detailed usage data across your different customers, simply because each of your customers’ data will be stored in completely separate instances.

Release Management

The only platform in the workflow automation space that provides any kind of release management process is Workato - as for the rest, there are no signals that a releases feature will be coming due to the focus on easy one-click deployments by citizen integrators.

❌ Difficult to implement via APIs - workarounds for auth required

✅ Workflow builder makes visualizing business logic relatively easy

⚠️ Workarounds required due to limitations from core B2C product

⚠️ Cannot programmatically manage users - only manually via the dashboard

✅ Generally sufficient monitoring tools

⚠️ Disjointed from existing release management process

Embedded ETL

Implementation experience

Similar to workflow automation platforms with embedded offerings, these platforms are not designed for multi-tenancy use cases (B2B).

As such, you are required to manage all the individual database instances to store each of your customers’ data.

Building the integration logic

Aside from mapping objects from your application to the 3rd party applications, no other business logic is supported.

However, if you only need sync integrations and nothing else, then this should not be a blocker.

Workarounds required

Again, only sync use cases are supported, and these platforms require additional work to set up a multi-tenant database structure. And unlike embedded workflow automation tools, where it is still possible to build workarounds to solve a problem that is not natively supported, any non-syncing use cases are simply impossible with embedded ETL platforms.

Programmatically managing users

Certain solutions enable you to disable/enable integrations programmatically, however schema mappings are handled by end-users on their own.

Monitoring & Observability

Logging is where embedded ETL platforms struggle. Given that there is no concept of an end-user in these platforms, all your customers’ logs will be grouped together with no way to segment them.

That means it is impossible to monitor the logs for a specific customer without manually parsing through hundreds, if not thousands of log files.

Release Management

Most embedded ETL platforms do not provide release management environments, as it is intended for internal data pipeline management.

Additionally, given the non-embedded nature of their core products, you need to manage each individual customers’ deployments separately, due to its B2C architecture.

❌ Difficult to implement via APIs - multi-tenant architecture is not natively supported

⚠️ Business logic is limited to object syncing

❌ Workarounds are not an option for any non-sync use case

✅ Programmatically managing whether or not a sync is enabled for a user is possible

❌ Monitoring tools are not designed for the embedded use case

❌ Disjointed from existing release management process

The decision within this category is simple - stick with the solutions that provide low-code abstractions in conjunction with the extensibility that developers expect from a dev tool. Streamline the repetitive, unnecessary work around APIs/authentication, but have the ability to build any use case you will ever need.

Integration Infrastructure

Integration infrastructure is a challenge that many companies overlook when scoping out their integration projects. Building auth and making a few requests for a handful of users is not necessarily that difficult. But at scale, with hundreds of users and dozens of integrations per user, things quickly start to break.

You’ll start to run into issues around concurrency, performance, and latency, and integrations erroring out multiple times a day.

Just as one example, let’s imagine all your customers’ integrations rely on the same task/job queue. if one user decides to upload a huge file that needs to be processed within a workflow, suddenly all your other customers’ integrations will be backlogged. So if real-time behavior is important when it comes to your integrations, this will not be acceptable.

That’s just one simple example amongst dozens of highly complex infrastructural challenges that you will run into as your company and integration requirements evolve.

To keep things simple here - unified APIs are the only solutions that do not provide a serverless infrastructure. The rest rely on the solutions provider’s infrastructure.

A few additional notes here:

1. Make sure you can vet the scalability of the solution provider’s infrastructure - do they have a track record of supporting high scale use cases/customers?

2. If you need to deploy integrations on-prem for security/compliance reasons, Paragon is the only option

Bespoke Integrations

Custom implementations

So what happens if you have enterprise customers that need custom integrations?

There are 3 options here that we'd recommend, in order from least to most recommended.

1. Provide them a public API to build their own API integration

2. Integrate with workflow automation tools like Zapier, Tray, or Workato, and have them build their own workflows externally on those platforms

3. Build user-specific workflows in your integration platform

The first two options are straightforward, because you absolve yourself of the responsibility of maintaining these custom workflows.

However, that is money left on the table that you could otherwise be getting via upselling enterprise customers on these bespoke workflows.

So, if you want your solutions engineering team to have the ability to build bespoke workflows for your customers within the integration platform, only embedded iPaaS and embedded workflow automation tools enable it.

Decision Tree

Picking the right integration platform to partner with is a loaded decision, because once your customers start using the integrations, it’ll be very difficult to rip the platform out of your product once you run into limitations.

We’ve even seen companies like Apollo.io pay for multiple platforms (Tray and Merge)  simultaneously because both had feature limitations. Others have had to re-build all their integrations on a new platform before moving off of their old solution - otherwise their customers’ wouldn’t be able to use the integration during the transition.

We don’t want you to make the same mistake, which is why we spent weeks researching each solutions category, from going through multiple vendors’ documentation in each category to signing up for trials in some cases, so you can make an informed decision.

However, this was also a lot of information to take in, so we’ve simplified the decision making process for you. We’ve put together 2 ways to help you determine which solutions category you should pick, both which are below.

1. Go through an 8 question multiple choice questionnaire

2. Use the decision tree

I hope this guide was helpful in helping you grasp which types of integration solutions are the best fit(s) for your native integration strategy.

While Paragon is the leading embedded iPaaS in the market, we believe that there are specific integration use cases that other solution types may be more suited for which is why we wanted to make this resource as transparent and unbiased as possible.

If you'd like to learn more about our product, feel free to book some time with us so we can walk through your requirements together, or sign up for an account here!