Embedded Integration Platform vs. iPaaS - The Key Differentiator

Every B2B SaaS company receives countless integration requests from both prospects and existing customers. The challenge arises when allocating developer resources towards those requests, since every hour spent on integrations is an hour that can’t be spent developing core product features. 

The two types of solutions that have emerged to solve this problem are embedded iPaaS (integration-platform-as-a-service) and traditional iPaaS (also known as workflow automation platforms). However, each solution category tackles this integration problem from a different angle.

So what’s the difference? Put simply:

• Product and engineering teams at B2B SaaS companies use embedded iPaaS platforms to build customer-facing integrations, between their application and their customers’ other tools. These integrations are commonly referred to as “native”,“out-of-the-box”, or ”one-click”, because end-users don’t need to do any of the configuration other than authenticating the 3rd party app. 

• iPaaS integrations are used by operations teams (oftentimes in marketing or sales) for internal automation. For example, a user might use a solution like Zapier to set up a one way integration between 2 SaaS apps that they use internally to perform their day to day tasks.

• Where it gets confusing - A B2B SaaS company may decide to build a connector for their app on the marketplace of a traditional iPaaS in order to offload the integration efforts onto their customers.

As you can tell, it’s no surprise that many people conflate the two. And it hasn’t helped that leading iPaaS companies have tried to repackage their core iPaaS product into a secondary, embedded iPaaS product (we’ll get into this later).

When thinking about how to scale your product’s integration roadmap, there is value in leveraging both types of solutions, but in different ways and for different purposes. At a high level, you can build a connector for your app on a traditional iPaaS platform to have your customers manage their own one-off integration requests, but any strategic integrations should be provided natively, and therefore built by your team via an embedded iPaaS. 

But first, let’s get into some more details on each solution type.

TL;DR

• Embedded integration platforms can be installed into your app via an SDK or a REST API

• They’re designed to be a toolkit for your developers to rapidly accelerate 3rd party SaaS integration development, while providing them full visibility into their customers’ integration executions

• Integrations built through an embedded iPaaS should feel completely native to your product - though that may not always be the case

• Traditional iPaaS platforms are used by operations teams to pass data between two or more internal tools.

• B2B SaaS teams can build a connector on these iPaaS platforms to be listed as an integration, so their customers use the iPaaS to set up and maintain the integration on their own dime.

• iPaaS platforms are meant for simple one-way data mapping, which means your customers won’t be able to build any complex integrations such as bi-directional syncing

• If you publish a connector on the iPaaS’ platform, you won’t have deep insights into what integrations your customers are building with your app, which subsequently makes it harder to diagnose any issues they run into.

• There’s no way for you to monetize integrations that your customers build through the traditional iPaaS. 

• Many traditional iPaaS companies have “wrapped” their main product to offer an embedded solution. 

• These wrapped, embedded solutions are not designed for developers because they are handcuffed by their core workflow automation products.

• In most cases, the integrations you build through these wrapped iPaaS platforms are also not whitelabeled

• The best approach is to use embedded integration platforms to build strategic, native integrations, and build connectors on traditional iPaaS platforms for anything your engineers can’t justify spending time on. Avoid “wrapped” solutions at all costs.

What are Embedded Integration Platforms?

Embedded iPaaS platforms get their name from being a layer that operates within your B2B SaaS product.

As such, your engineering team will be the users of the Embedded iPaaS, and your customers will be the end-users of the integrations that your engineers build.

Ideally, though this is not the case with many embedded iPaaS solutions, the outcome of using an embedded iPaaS is that from your customers’ perspective, it’s as if you built the integrations in house.

When you use an embedded iPaaS to build integrations, your users won’t need to define the integration logic - all they need to do is authenticate their 3rd party account (via OAuth 2.0 or API Keys) and enable the integration functionality that you provide out of the box.

So what are some of the key attributes of a robust embedded iPaaS solution? Let’s take a look.

The developer experience

The best embedded integration platforms are designed specifically for developers, as integrations are a core component of every SaaS product and needs to be owned by your engineering team. Despite that, however, the developer experience is still a key differentiator between platforms.

While the goal of any embedded iPaaS is to minimize the amount of unnecessary work engineers typically have to do to build an integration, only a handful provide the extensibility of building completely in-house.

This manifests across different components of the entire feature set.

Pre-built connectors

Embedded integration platforms generally provide pre-built connectors that offer a layer of abstraction on top of 3rd party APIs (referred to by us as Workflow Actions). Unlike with building integrations in-house, this saves your team from having to parse through esoteric third-party APIs for a majority of the most common endpoints.

Additionally, the team behind the embedded iPaaS will maintain all those abstractions, meaning if the 3rd party API changes, your own engineering team will not be burdened with managing those updates.

While these API abstractions generally cover 90% of the use cases you may need to build, the best platforms provide full parity to the 3rd party API because not all endpoints will be abstracted. In practice, this means you should be able to easily access the full 3rd party API for any non-standard use cases.

Workflow builder

As hinted by the screenshots above, most embedded iPaaS platforms provide a workflow builder for you to easily define the integration logic for an integration use case. However, there is a huge variance in the developer experience and extensibility of the workflow builders between different platforms.

For example, it may not be easy (or possible) to transform data, provide your customers dynamic field and object mapping or surface custom user defined variables/metadata with certain platforms.

As a plug - Paragon provides the best developer experience when it comes to our workflow builder. Whether you want to write custom javascript functions, import npm libraries, or provide users the ability to pass custom schema mappings, it can all be done without any workarounds.

You can give it a try by signing up for a trial here.

Authentication

One of the biggest pain points when it comes to building native integrations is managing your customers’ authentication, which consists of securely storing your customers’ credentials and managing access/refresh tokens when it comes to OAuth based auth.

Certain embedded iPaaS platforms will provide fully managed authentication, to save you the headache of dealing with the complexities of each app’s auth mechanism, and this experience is generally white-labeled for your end-users.

A seamless integration experience for your customers

The main value prop of embedded iPaaS solutions is that they enable you to provide your customers a seamless user experience, as with any other native integration you may have built in-house.

As mentioned earlier, your customers shouldn’t know that you are using a platform to provide them these integrations, as the user experience should feel fully native and white-labeled.

For example, the Connect Portal that Paragon allows you to surface to your customers is a fully white-labeled JS modal that is highly configurable, and our headless implementation takes that a step further.

However, the end-user experience may vary depending on the embedded iPaaS solution. The most common implementations outside of a native JS modal are:

• A redirected 3rd party URL where your customers will authenticate and configure their integrations

• Via an iFrame or an external integration hub

• An inflexible embedded in-app page that is managed by the 3rd party platform

Observability and monitoring

Another benefit of embedded integration platforms is that they come with built-in logging to assist with diagnosing and solving any issues that arise with your integrations, be it an end-user issue, downtime with the 3rd party app, or any other bug.

Each execution and its payload should be logged automatically, providing visibility across your entire integration infrastructure.

This means that you can often catch issues and start debugging them before they negatively impact your customers, accelerating your incidence response time. 

‍

Additionally, a select few solutions offer robust monitoring and event flagging tools that will notify you whenever an error occurs for an end-user. This not only allows you to reduce incidence response times, it can also help you prevent errors from causing critical data loss.

Since your customers aren’t configuring the integrations on their own, as they would do with a regular iPaaS platform, you’ll have complete control over the integration’s performance which leads to far fewer support headaches.

Now that we’ve covered embedded iPaaS, let’s talk about how traditional iPaaS platforms are different.

What are iPaaS platforms?

You may be familiar with platforms such as Zapier, Tray.io, or Workato - these are popular iPaaS/workflow automation platforms. These iPaaS platforms typically serve two main use cases - one for their customers, and one for their partners.

For the iPaaS customer

Companies pay for iPaaS solutions to connect two or more internal tools together, generally as a way of automating parts of their operations. The reason this market exists is because the integration the customer needs does not exist natively, or the native integration does not cover the use case the customer requires. This is often the case with marketing and sales ops teams who need a lot of integrations to pass data between their different platforms, yet the platforms don’t offer the integrations out of the box.

For example, as a SaaS buyer, if you wanted to get a Slack notification everytime someone booked some time on your calendar, you could leverage an iPaaS to configure that automation yourself (if they didn’t have that integration).

For the iPaaS partners (B2B SaaS companies)

From a B2B SaaS perspective, you could integrate/partner with iPaaS platforms as a way offload the integration work onto your customers (making them a customer of the iPaaS).

In this use case, you would not be the end-user of the iPaaS. Instead, you would build a connector for your app and publish it on the iPaaS platform. That way, your customers can go pay for the iPaaS solution, and select your application as a step when they build their automations.

‍

Companies often opt for this approach because as we know, engineering time is scarce, and so rather than building integrations in-house, many B2B SaaS companies leverage this approach to ‘solve’ their integration challenge (despite the downsides of this approach).

Examples of iPaaS integrations

Here are some ways that iPaaS integrations can look like.

In this first example, Gong integrates with iPaaS vendors Zapier, Workato and Tray, and requires their customers to set up the integrations on their own.

From your perspective, your customers may use an iPaaS to build automations that trigger Slack notifications whenever certain activity occurs in your app.

Building a connector on the iPaaS platforms and pushing your customers to configure and maintain their own integrations is primarily useful for dealing with obscure integration requests that only a few of your low-tier customers ask for. 

Regardless of how many engineers you have on your team, if only one customer asks for an integration (with enterprise customers being an exception), it would be hard for you to justify building that integration natively, even if it only takes 3 days with an embedded iPaaS. However, this approach is not a silver bullet for your integration strategy.

Ultimately, any strategic integration that’s requested by a sizable number of your customers should always be provided natively to your customers, right out of the box. Here are a few reasons why.

Challenges of integrating with iPaaS platforms

1. Support / solutions engineering headache

Unless you sell into a highly technical audience, your customers will likely need your help to set up their automation workflows. As a result, your team will need to spend hours screensharing with customers to help them set up (or debug) the integrations they need.

This is not scalable, as even if multiple customers had the same use case, you’d need to walk through setting it up with each of the customers as their iPaaS instances are unique.

As a real life example, when conversational AI platform Structurely was using Zapier to manage their integrations, their solutions engineering team had to spend 10-20 hours a week just building and maintaining Zaps on their customers’ behalf. This alone ultimately drove their strategic transition towards building integrations natively with Paragon.

2. No insights into customer integration activity

From a product insights perspective, you won’t be able to tell which categories of integrations customers are using the most - an important data point that is crucial for prioritizing your native integration roadmap.

Additionally, not knowing how your customers have configured their integration and not having visibility into their logs can be a nightmare when it comes to providing customer support.

Unlike embedded iPaaS platforms, which provide you with detailed logs on all your integrations so that you can diagnose any problems with your customers’ integrations and fix them before they get out of hand, you won’t get any of those insights by using a traditional iPaaS.

3. Not designed for high volumes of requests

Traditional iPaaS platforms are designed for simple one-way, automation-based integrations. If your customers have any use cases that aim to keep data consistent across platforms, aka via a bi-directional sync, it is simply not feasible. Every time a field of any object is updated in one platform, they would have to trigger a task execution to update that field in the other.

Not only will your customers be frustrated that they have to set up two workflows for every object type that they want to sync, the costs can easily grow into hundreds, if not thousands of dollars a month.

Monthly cost = 2 * # object types * # of objects * # field updates/month * cost per task

This leads right into the next downside.

4. No ability to monetize integrations

If you use a traditional iPaaS rather than building the integration natively, you’ll lose out on the option to upsell the integration to your customers. 

Continuing with the bi-directional example, wouldn’t you rather build it once and offer it to all your customers, and have the option to upsell them on it at a fraction of the cost they’d be paying the iPaaS solution?

Most of your customers would prefer to pay you for the integration rather than going through a third party iPaaS, since it would save them the time and cost of configuring and maintaining the integration themselves.​​

5. An incentive to churn

Most of your customers will struggle to build and maintain the integrations they need on an iPaaS solution on their own. Unfortunately, if things break or stop working properly, even if it’s due to mistakes they themselves made, it reflects poorly on their overall experience with your product.

So if your competitor provides the same integration natively, there’s a strong incentive for your customers to switch.

We’ve experienced this ourselves here at Paragon, as end-users of SaaS platforms. Our sales ops team had to use Zapier to integrate Calendly and Salesforce, which caused a lot of headache. Every time a new sales rep joined the team, we’d have to create new a new workflow specific to them, and whenever we needed to update a mapping, we’d have to update it multiple times for each rep’s workflow. When looking into lead routing tools, we learned that Chili piper offered a native Salesforce integration that handled that out of the box - as a result we’ve since switched over from Calendly.

Don’t let that happen to you. 

iPaaS platforms with an embedded solution

In this article, we’ve tried to communicate the differences between iPaaS and embedded iPaaS platforms as clearly as possible. But not all the providers on the market fit so neatly into one category or the other.

Since Paragon’s launch, multiple traditional iPaaS companies have seen the opportunity presented by the embedded model and attempted to capitalize on it. The textbook example here is Tray. Known for its traditional workflow automation iPaaS, Tray has now “wrapped” their iPaaS solution so that they can offer it as an embedded iPaaS, called Tray Embedded. 

On the surface, this sounds like a great idea, as they can leverage the connectors they’d built for their core product. Unfortunately, their ability to deliver an embedded product will constantly be hindered by the DNA of their core product which is designed for operations teams, not developers. Unlike other platforms that offer secondary products, these embedded solutions are built on top of the existing iPaaS product, which means every use case requires a workaround.

Consistently, these workaround embedded iPaaS solutions provide a means for your customers to access their iPaaS platforms within your app, making each of your customers a tenant of their product.

This structure creates challenges that present themselves through multiple fronts, including:

• A disjointed auth experience for your customers

• Lack of developer support

• A distracted product roadmap (not being able to focus on embedded features)

• Lack of self-hosting options

Not white-labeled

One of the biggest advantages of a truly embedded integration is that the customer experience is seamless. 

But if your embedded integration platform is a traditional iPaaS with an embedded workaround solution, then expect redirects to the iPaaS’s domain, like this:

Or, perhaps worse, fragile iFrames that put your iPaaS provider’s brand front and center, not yours:

Examples like these make it apparent to your customers that there’s a 3rd party platform involved, and can lead to a disjointed and confusing experience, as well as data privacy and security concerns.

Non-technical support

Since the core business of these platforms is in the internal automation space, their support is focused on troubleshooting issues for operations teams, not developers.

However, if you're using their embedded iPaaS solution, your issue will require technical support more often than not. Consistently across calls with prospects, we know that though your issues may eventually get resolved, you'll have to go through layers and days of non-technical support.

Distracted roadmap

As we mentioned earlier, if you have a feature request for their embedded product, the odds of it getting fulfilled are very minimal.

Ultimately, the core of the iPaaS and embedded iPaaS products are one in the same - it's not possible to build a meaningful and extensible developer-oriented product while catering to their core customer base of non-technical users that want a no-code solution.

Lack of on-premise deployment

If your customers have strict security requirements that prevent you from having their data flow through 3rd party cloud servers, you’ll need an on-premise solution. However, due to the nature of iPaaS platforms’ core infrastructure being cloud-based, there is simply no way for them to offer self-hosted instances of their product.

This can lead to significantly longer and more complicated sales cycles with security-conscious customers, and might even require you to get your iPaaS platform to pass security reviews as well.

Why SaaS companies need both embedded iPaaS and iPaaS

At this point, you might think that we’re trying to communicate that building a connector with traditional iPaaS solutions is a poor substitute for an embedded iPaaS. But it’s not as simple as that. 

In fact, the two options aren’t mutually exclusive - both platforms have their place as part of your strategy. 

An embedded integration platform is the best choice for any strategic integration that adds value to a meaningful part of your customer base. There’s no better way to save months of engineering time, accelerate your integration roadmap, and out-compete rival SaaS companies by offering better integrations all while providing a seamless and native customer experience.

That being said, there will always be integrations that are further down your integration backlog. In those instances, you may not be able to justify spending scarce engineering resources on honoring those requests, but you can point those customers towards using your connector on traditional iPaaS platforms. The only time when you might want to build these integrations natively is if the 1-2 companies that are requesting them are so large that the deal size justifies the engineering expense, which some of our larger enterprise-serving customers have done.

The one hard-and-fast rule for planning your integration is never to use “wrapped” embedded integration platforms. We constantly encounter companies who’ve churned from these types of platforms due to the challenges we raised in the previous section. 

Conclusion

Now that you’ve read this article, you should be in a better position to understand the differences between an embedded iPaaS and a traditional iPaaS, and how each can fit into your SaaS product’s integration strategy.

If you’re looking for an embedded integration platform that was built for developers from the ground up, Paragon is the solution for you. While others in the space have taken a no-code approach, ultimately your engineers will always be the owners of the native integrations you build for customers, and deserve a platform that delivers on that developer-oriented experience.

To learn more, book a personalized demo today, and we’ll walk you through your specific integration use cases.