Embedded iPaaS is a class of integration software that allows SaaS vendors to "white label" or "embed" an existing integaration product's capabilities into their own.
This approach prevents the SaaS vendor from having to reinvent the wheel, building an integration infrastructure from scratch. It allows them to, instead, focus on the specific integration uses cases that address specific user needs.
Embedded iPaaS is a relatively fresh approach to integration, and many SaaS vendors are starting to consider it. The demand for more integrations isn't getting any smaller, and embedded iPaaS potentially offers a way to keep up with this demand.
But, no solution is perfect!
In this post, we break down some of the more important pros and cons of using an embedded iPaaS to enable connectivity for your SaaS product. Understanding them will help you assess if embedded iPaaS is the right solution for you.
Not all embedded iPaaS products are created equally. Even though "embedded iPaaS" is a subset of iPaaS overall, you can actually break it down further than that. This is important, because it might have impact on your experience with the iPaaS and whether it'll help you achieve your connectivity goals.
Note: If you need a refresher on iPaaS, this is a decent overview.
Roughly speaking, consider these three types of embedded iPaaS:
No one type is necessarily better than the other. There are tradeoffs that will mean different things to every business. Let's dive a bit into each one to understand their differences.
You might be able to gather by its name, but purpose-built embedded iPaaS products were always supposed to be embedded iPaaS. The white label, embedded, or OEM approach (whichever term you prefer) is core to their DNA. The product is fundamentally designed and architected around the SaaS connectivity use case.
Compared to traditional iPaaS, embedded has additional complexities to contend with.
If you are evaluating embedded iPaaS products, you can generally consider whether its purpose-built for embedding a positive quality. That doesn't mean other models aren't valid as well, and it doesn't mean that every purpose-built embedded iPaaS is better than every traditional iPaaS for meeting your needs. You also must consider that, since this is a relatively new approach to SaaS integration, your options are much more limited.
Pro Tip: You may need to go beyond what the website says when you're evaluating what appears to be a purpose-built iPaaS. There are vendors who started as traditional iPaaS, but pivoted early to the "embed" approach. This means their product, at least early on, was NOT purpose built for "embed" use cases. Use the Wayback Machine to evaluate how they originally marketed their product to sniff out if this is the case. Then ensure they can communicate why they made the change and what the did with their product to ensure it's optimized for the "embed" use cases.
It's also not a requirement that you use a commercially available embedded iPaaS. You can consider embedding an open source integration framework, like Open Integration Hub, into your product. There are certainly trade-offs to doing so, but it gives you full ownership and control of the integrations and the data they move.
Many traditional iPaaS vendors now offer "embed" features that allow their product to behave as an embedded iPaaS. This is probably the most prevalent type of embedded iPaaS products out there, because 1) the iPaaS space overall is crowded and well-established and 2) many of these vendors are realizing that "embed" uses cases support better unit economics. Read: R&D and marketing dollars are funneling here.
With traditional iPaaS-turned-embedded vendors, you'll need to understand how far their "embed" features go. Sometimes vendors will market with "embed" or "white label" messaging, but their offering isn't much more than a different business arrangement (charging the SaaS vendor, not the end user). Others have actually built out some amount of features for embedding, like APIs and dev tools.
One advantage to this type of iPaaS is that many of these vendors have been around for a while and have demonstrated success. Going with traditional iPaaS with embed features opens your possibilities to more established players.
There are also vendors who effectively offer embedded integration capabilities, but don't necessarily call themselves an embedded iPaaS. Typically, this is because, while SaaS integration is part of what they offer, their product vision is built around other related features. For example, some products market more around the fact that they help you build out an integration marketplace more than the data integration engine itself.
These are also vendors that might satisfy your connectivity needs, so they should be considered (generally speaking) as embedded iPaaS...at least for the purposes of this pros and cons list.
You've got options when it comes to the type of embedded iPaaS product you can choose. But, should you actually be using an embedded iPaaS in the first place? There are pros and cons.
Let's start with the positives! There are some significant pros to using a commercial embedded iPaaS to enable SaaS connectivity. The following are some of the bigger ones.
Commercial embedded iPaaS vendors typically have large libraries of connectors to commonly integrated systems. This is even more true of longstanding traditional iPaaS vendors who now offer "embed" features.
These connectors simplify the integration build process by normalizing common integration use cases. They help shield your integration team from having to develop deep expertise in whatever system they connect, which speeds up integration projects overall.
The possibility exists with every connector that it's not actually very well developed or not developed around your use case, but most commercial embedded iPaaS vendors also offer frameworks and processes for extending existing connectors.
If a connector-based approach is right for your integration strategy (read more here), these large, established libraries are a big advantage.
A huge advantage of using a commercial embedded iPaaS is that you offload most of the infrastructure responsibilities to a third party. If you're a small team or you don't have the desire or budget to hire people dedicated to these areas, this helps you level up fast.
Moving data as a SaaS vendor on behalf of your users is not trivial. You have to move a lot of data without dropping it on the floor. This can be expensive if your team isn't experienced architecting these types of systems. It can send your cloud bill through the roof in the worst cases. It can also put you in a position to hire more cloud engineers than you'd otherwise want to.
With a commercial "as a service" product, you're effectively outsourcing your cloud management to that vendor--at least for the parts of your product that relate to integration. You're going to have it marked up (they are a business after all), but that still might be less expensive than you building the team and optimizing the cloud computing spend.
Many embedded iPaaS offerings started as traditional iPaaS. Some of them offer the ability to use their product internally (as traditional iPaaS) to integrate your systems and automate business software and externally by enabling connectivity for your product and its users.
This potentially allows you to kill two birds with one stone in terms of software integration. It expands the footprint of the new integration capability within your organization, helping you to automate internal processes. It also increases the overall awareness of and competency using the embedded iPaaS, because more people on your team will potentially be involved.
Often in a SaaS company, the engineering team's time is limited. That means when it comes to getting integration projects completed, often to primarily serve the needs of the marketing, sales, or partnership teams, there can be a lot of prioritization challenges.
Most embedded iPaaS products include low-code editors that help non-technical or semi-technical people build out integrations. Using an embedded iPaaS opens up the possibility that you don't need an engineer to build every product integration. This potentially reduces that prioritization friction.
Now, this is a big MAYBE in terms of whether it's a pro or, as you'll read shortly, a con.
Low code tools focused on non-engineering team members are right for some organizations and wrong for others. Don't just take it as gospel that this is necessarily a win. You must really think about who's on your team and how they want to operate. If your team wants to keep integration within the product and engineering teams, there are other ways to get similar effort reduction advantages that don't involve using tools that aren't really built for and will often frustrate engineers.
With every decision there are downsides as well. The following are some potential cons to consider when looking at using an embedded iPaaS to enable SaaS connectivity for your software product.
Connectivity is an important, fundamental set of features for your product. You don't get to choose whether it's important, because your users demand that it is.
Choosing to use an embedded iPaaS product to build out those connectivity features has advantages, but it also means that you've locked yourself into a vendor for a very important part of your product. This is a decision that is not easy to undo, and it's very expensive to undo.
People rarely rip out a working integration for the sake of replacing it. That's because migrating or redoing an integration is hard and sometimes expensive work. And, ripping out to replace an existing integration means spending that money and doing that work to end up roughly where you started. Unless you are replacing a failing integration, the juice is often not worth the squeeze.
If you use an embedded iPaaS to set a bunch of your users up on a bunch of those integrations, you've now signed up for the responsibility for what happens if your relationship with the embedded iPaaS vendor sours. What if they go out of business? What if they're acquired? What if they triple their price?
Committing to an embedded iPaaS is more like a marriage than it is like a friendship, so the appropriate due diligence should be taken when considering the approach.
It's generally less expensive to make your dinner at home than it is to buy the same meal at a restaurant. You go to the store, you buy the ingredients directly, and then you do the work yourself. The restaurant has to pay someone to make the food, pay for the rent, and all the other expenses a restaurant takes on. So, on a per meal basis, you're exchanging your time for a marked up meal and a different experience.
The same is true when using a commercial embedded iPaaS for your integration approach. There is a lot you don't have to do (like architecting a high scale integration framework), but you're going to pay for a marked up version of it.
The tradeoff is worth it if the embedded iPaaS significantly reduces your time to market for the integrations (it takes you three hours to make microwave macaroni and cheese). The product might also offer benefits you couldn't build yourself (a gourmet meal beyond your home cooking skills). But, if your team is pretty integration-capable without that extra commercial product, you may take on unnecessarily marked up costs in addition to the vendor lock-in.
Open source alternatives do limit your exposure here as well.
Both the vendor lock-in and the potentially higher operating costs that embedded iPaaS brings may also have an impact on the value of your business. This is particularly important to consider if you are backed by investors who expect a return on the investment they put into your company.
If you build integrations on an embedded iPaaS, you do not own the integrations. You are borrowing them (and paying to do so). This creates a critical single point of failure for the business, which adds risk. It also means you are effectively renting what might be seen as an absolutely fundamental set of features. A potential acquirer or investor may flag that, causing the company's value to be perceived as lower.
This is a big reason why venture investors should care about integration too.
Depending on the makeup of your team, the problems your product solves, and how you get work down, the low-code, non-technical focus that many embedded iPaaS products offer may not actually be a benefit. It might be quite the opposite.
You'll often hear engineers scoff at low-code tools, because they make the job harder to do. When you're using a low-code tool to make something happen, you're still programming. You're just doing it using a visual editor, not literally writing lines of code (that's happening under the hood).
If your team is skilled in writing code, the low-code tools actually might get in the way. They give an engineer an unnecessary added layer to think through and it prevents them from solving the problem directly. If you have an engineering-heavy team, this might be a non-starter for the embedded iPaaS conversation. They may simply be more effective without it.
This post was all about the pros and cons of using a commercial embedded iPaaS for building SaaS connectivity, but there are other approaches as well. This post discusses some other ways you can handle connectivity, and we often advocate for a portfolio approach that leverages more than one.