The significance of embedded iPaaS has significantly risen in the past months. This can be easily seen by reviewing the search volume for the keyword “embedded iPaaS” – if in October 2019, for example, there were only a handful of queries for this term, by the first quarter of 2022, the search volume has increased by 1500%. Yes, you’re reading it right, this is not a typo – by one thousand five hundred percent.
Such a tremendous increase in people searching for embedded iPaaS can be attributed to two forces joint together: SaaS vendors realizing they can hardly cope any longer with an increasing demand for integrations from their customers, and iPaaS vendors realizing there is a largely untapped market of great potential for business growth and new customer segment.
Let’s begin, though, with a brief overview of what exactly is meant by ‘embedded iPaaS’ and why it is gaining in attention from SaaS vendors.
What is embedded iPaaS?
Well, an (extremely) short answer to this question is – it’s a third-party iPaaS solution that is part of another software solution but is not directly visible or recognizable as third-party element (I assume you already know what ‘iPaaS’ is – that is integration platform as a service –, hence we’re going to use this acronym throughout the text).
While the term ‘embedded iPaaS’ may seem new, the actual concept of ISV vendors embedding iPaaS integration services into their own software solutions was evaluated by Gartner (who else?) as early as in 2012 when they published a paper titled “Benefits and Drawbacks of iPaaS as an ‘Embedded’ Feature of Cloud Services” (paywall).
In the following years, the adoption of iPaaS by SaaS providers for embedding purposes was slowly increasing until – boom – there was an explosion of integration marketplaces and plug-and-play integration solutions provided by SaaS vendors, and requests for embedded or white-label iPaaS from SaaS vendors – something we, as an iPaaS provider, experienced first-hand.
This leads us to the next question:
Why do you need an embedded iPaaS?
That is, if you’re a SaaS vendor. Back in 2019, I wrote an article on why customers are looking for software ecosystems rather than software products. While this claim is intentionally provocative, it’s not far-fetched from reality.
Integrations with other business software solutions, cloud based but also on-premises, play an increasingly pivotal role in any B2B SaaS product offering. The messages that we often get go somewhere along the following lines:
- “At the moment we’re servicing about X number of service providers for which we build custom integrations and we’re investigating other options to make integrations work”
- “We want to replace our existing integration capabilities of our software with an iPaaS solution”
- “We provide a SaaS solution for XY, and we are looking for the integration tools that can sync data from any other 3rd party software to our solution”
- “We are looking for a way to offer integrations within our own application”
The scenarios, industries and requirements vary, but one thing is common to all such messages – they come from SaaS vendors who, for some reason, want to address their own customers’ integration needs in a more efficient way.
The reasons for that vary, too. The most common ones we’ve encountered so far are:
- Desire to create a more compelling offering by lifting the burden of developing integrations off of their customers
- To decrease the workload of own IT teams with respect to the development of custom integrations
- To modernize already existing integration capabilities by separating integration logic from the core business logic
But whatever the reason is, it is clear that SaaS vendors are increasingly searching for embedded iPaaS solutions because the way how integrations have been handled in the past became unsustainable, and now hinder the product growth and adoption speed.
Types of embedded iPaaS
Now that we’ve established that it’s not some modern trend that’s going to abide soon, let’s go over the currently available options for SaaS vendors to leverage the capabilities of iPaaS to their own products’ advantage. In this context, I’m going to apply the term “embedded iPaaS” a bit more loosely as some of my industry colleagues might do.
White-label iPaaS
Also known as OEM iPaaS, although this particular name is far less used in this context, this type of embedded iPaaS represents a product that is shipped in its entirety to the SaaS vendor, who on his side, adjusts the UI / UX to match their own SaaS solution.
The key characteristics of a white-label iPaaS should include:
- Multitenancy
- High scalability and low latency
- Integration management API
Multitenancy
Any B2B SaaS vendor knows this concept first-hand, since it offers its product to multiple customer companies. With white-label iPaaS, there is even an additional layer of tenancy, since it serves the platform to multiple SaaS vendors who, in turn, serve it to their customer organizations.
High scalability and low latency
This criterion is important for any iPaaS offering, but with white-label iPaaS, the importance is double if not three-fold, because the number of end-users from each SaaS vendor using the platform can go into hundreds if not thousands.
Integration management API
Just like any iPaaS leverages the power of APIs to build connections to various applications and services, the platform itself should ideally provide API endpoints for various events such as ‘create a contract’, ‘start a flow’, or ‘update a pub/sub topic’ – because you might not know at the beginning of the project how you end up integrating the iPaaS into your SaaS product.
Some other desirable characteristics include documentation that can be as easily white-labeled as the platform itself, and microservices architecture in case when you as a SaaS vendor would like to embed the platform into your application on a very deep level.
The purpose of adopting white-label iPaaS for SaaS vendors is to not only build and re-use integrations that their customers want faster as compared to doing this in-house, but also to enable the customers to do the integration work themselves should they wish so – all under the “umbrella” of one’s own SaaS brand and one’s own URL.
The main advantage of this approach is that it decreases the development burden from all IT teams involved. There is a disadvantage, though, too – such a solution addresses the needs of the clients’ IT but not its business users. Configuring an integration flow, even when most of its steps and elements are pre-built (e.g. connectors for business applications) might require at least some level of technical knowledge that regular business users are unlikely to have.
Curious to learn more about how other SaaS providers use iPaaS to extend integrations capabilities of their products?
In this case study, we cover three stories – so you’ll get three for one 😉
Download the embedded iPaaS collective case study –>
Self-service integration marketplace capabilities
This type of embedded iPaaS works rather in the background while the end users will get to see one-click, pre-built solutions for integration flows and scenarios they are likely to require. Think Zapier-like recipes only offered within your own SaaS product.
The key characteristics of embedded integration marketplace offering should include:
- Multitenancy
- Recipes functionality
- Marketplace functionality
Multitenancy
Just like with the white-label iPaaS type, the provider of the platform for integration marketplaces will address multiple SaaS vendors who, in turn, will address their own end-users. Hence multitenancy is in this case is an equally critical feature.
Recipes functionality
This might be called differently, but the idea remains the same: You should be able to build fully-functional solutions for popular / requested integration scenarios that can be activated by the end user with just a few clicks and minimal technical knowledge or input. Ideally, there is an API endpoint that facilitates recipes management and implementation on your side.
Marketplace functionality
Just like retailers would use a marketplace software to create and manage online storefronts, the same kind of experience should be provided by the iPaaS vendor for its SaaS customers too. So that you as a SaaS vendor can choose yourself which integrations you’d like to include for your end-users, as well as have the freedom to group them into logical categories, specify logos and icons, integration descriptions, titles, and more.
It goes without saying that the UI / UX of such self-service integration marketplace should also be easily modifiable to reflect a respective SaaS brand.
The purpose of adopting this type of integration offering is for SaaS vendors to offer its customers a fully pre-configured, “sit-back-and-relax” solution to their integration needs.
The advantage is – there is minimal effort from the end-users’ side to activate and use the required integrations, hence it is ideal for addressing business users.
The drawback is, though, that your own development team will get to do all the work regarding recipe creation themselves. In addition to that, such pre-built scenarios will be able to address only the common integration needs and scenarios; more complex ones will require custom development after all. However, the usage of iPaaS itself will reduce the overall development effort considerably, so it is still a much better option than in-house development and maintenance of each single integration.
Which type is right for me?
If only there were a crystal ball to look into and know the answer. Really, it depends on so many factors to be counted in.
- Is your SaaS product of an “extremely-easy-to-use” or rather a “quite-complex” type?
- What integration scenarios do you expect to be most common: very straightforward, “one-off” data or file exchange or something that involves more sophisticated business logic?
- Who do you want to build and facilitate integrations for: B2C consumers, your B2B customers’ business users or rather their IT teams?
- Do you want to allow the users of your integrations more flexibility and customization or is this not necessary?
These are only a few questions you might need to answer to determine which type of embedded integration solution is suitable for you. You might also change your strategy mid-way: Say, you started testing a platform with an idea to offer its UI to your end-customers, realized that it might be too technical for them but loved how flexible and powerful the tool is to speed up your own development of integrations with third-parties and custom APIs (true story, by the way).
Whatever your requirements and plans are, start by looking into the capabilities of the embedded iPaaS providers you’ve selected for testing. The lists of characteristics above should give you an idea of whether a platform meets the standards at least from the perspective of its technical capabilities.
