Top embedded iPaaS alternatives in 2024

Embedded iPaaS systems are one way of building integrations between your product and external APIs.

They aim to make building integrations fast, reduce the maintenance needed, and be accessible enough to allow anybody in your company to build integrations.

However, in reality they pose many challenges and often don’t live up to their promise.

In this article, we will look at the problems associated with embedded iPaaS and a few alternatives, which may help you achieve your goals better.

The Problems of Embedded iPaaS

A key promise of embedded iPaaS is that they let anybody in the company build integrations for your customers.

Unfortunately, in reality this often not the case:

• Despite low-code/no-code, almost all integrations still need to be written by engineers
  Integrations require detailed knowledge of your data model and product internals. This is something only engineers have in the company and even low-code and no-code workflow builders can’t change that.
• For developers, low-code/no-code is generally a bad experience
  If developers are primarily going to handle integrations, having them write code in a text field in a web app is neither a good, nor an efficient, development experience.
• Limited API coverage with workflow steps
  The pre-built workflow steps offered by most embedded iPaaS providers only cover a small part of the API. For the rest, you either have to write custom API requests in the web editor or resort to custom integrations built in-house.

With these limitations in mind, you might want to explore alternatives to embedded iPaaS. 

In the following sections we will look at three such alternatives.

Alternative 1: Building Integrations 1 by 1 In-house

If your development team has some free resources at their disposal, you can consider developing integrations on your organization’s infrastructure.

This requires reading through the external API’s documentation, building infrastructure (such as OAuth flows, scheduling and background jobs, data caching, de-duplication, rate-limit handling…), and building the whole integration manually. 

The benefits of this approach are:

• Full control over the integration
  You can build exactly the functionality you need for your integration. This allows you to perfectly align the integrations with your customer’s needs.
• Works with any API
  You are not limited by any external vendor and can build integrations with any API out there. It is rare that an external vendor supports all the integrations you need out of the box, so this escape hatch can be very important.
• Full control over data residency
  Compared to embedded iPaaS, building in-house has the advantage that the data never leaves your own infrastructure. In the case of sensitive businesses, such as financial providers, this can be a crucial factor in determining the mode of integration.

There are also a few downsides to building integrations in-house:

• More engineering work
  You need to build your own infrastructure to handle OAuth, data syncing, pagination, retries, rate-limit handling, data caching, deduplication, etc. You also need to understand every external API in detail. This requires extra resources and effort from your engineering team.
• High maintenance
  Building integrations in-house means you will also need to maintain them over time. If an API changes, the infrastructure breaks, or production issues come up you will need to fix it all yourself. Even with just 2-3 integrations this can become a big time sink.
• Time to market
  Building integrations in-house usually takes weeks to months and may delay deals from closing.

A common way to build integrations in-house is to build them directly into your app. For this you can leverage workflow orchestration platforms like Temporal and Cadence to deal with some of the complexities.

But fundamentally you will need to build all the logic yourself.

Alternative 2: Closed Unified APIs

Closed unified APIs aggregate many different APIs into a single API.

They provide similar infrastructure as embedded iPaaS, in that they take care of OAuth, data syncs, caching, rate-limit handling etc. for you. Also, they offer a much better experience for developers, rather than aiming to be low/no code. 

But they are entirely pre-built integrations, so unlike integrations built in-house or with an embedded iPaaS, you can not customize them or build bespoke integrations on their platform.

The advantages of using a closed unified API include:

• Integrate once, get many integrations
  Because unified APIs aggregate different APIs together, you only need to integrate with a single API to support many integrations.
• Low maintenance
  Since you do not integrate with the APIs directly, you do not need to maintain your integration logic over time. The unified API provider will make sure the integration keeps on working as expected.
• Uniform documentation and support
  When integrating multiple APIs directly, you need to sift through each of their technical documentation. With the unified API you only need to understand a single, well-documented API.

But closed unified APIs also have some issues:

• They limit what you can build with the API
  Because they aggregate different APIs together, closed unified APIs can only implement the features that are available in all of the APIs they aggregate. This becomes an issue when you try to build deeper integrations with bigger and more popular systems (e.g. a Salesforce integration), which have many features the others don’t have.
• You still need to build some integrations in-house
  Closed unified APIs do not let you extend or build integrations on their platform. If you need something that is not covered by them, you again have to build integrations in-house from scratch. It might be even worse, as you have to work around the restrictions of the closed unified API in addition to working with the external API.
• Limited APIs covered & no control over coverage
  Closed unified APIs will only integrate the APIs that are sufficiently popular. They may be missing APIs you need and in this case you have little control over if and when they get added.

Some examples of closed unified API providers include Apideck and Merge.dev.

Alternative 3: Open unified APIs

Open unified APIs are very similar to closed unified APIs, except for one key difference: they let developers fully customize integrations, as well as create new ones, on their platform.

This gives you unified integrations and custom ones on the same platform, so you never again have to build in-house from scratch.

It also means that there is no limit on the APIs you can work with through the platform. New APIs can easily be added to the platform by you, the user, without having to wait on the platform itself. And you always benefit from the pre-built infrastructure of the open unified API.

The benefits of using an open unified API include:

• Integrate once, get many integrations
  With an open unified API you truly get a single API and interface for all your product integrations. Unified, customized and entirely custom integrations are available through the same API and leverage the same infrastructure and pre-built components.
• Low maintenance
  Open unified APIs help you a lot with the maintenance of your integrations: Where you use pre-built ones or customize them, maintenance is fully taken care of for you. For fully custom integrations built on the platform you still benefit from many pre-built parts which are maintained for you (e.g. pagination, rate-limit handling, OAuth flow etc.).
• No limits on the integrations you can build fast
  With full access to the platform and the external API you can build exactly the integration your customers need, fast. You can start with a large set of ready-to-use integrations and can easily add more or customize them as needed.

Even open unified APIs are not perfect, and they also have some drawbacks:

• If you build custom, you still need to understand (some) of the external API
  Many parts of working with the external API are pre-built for you ((O)Auth, pagination, retries, rate-limit handling etc.), but if you build custom integrations on the open platform you still need to understand some parts of the external API.

Nango is an example of an open unified API.
It provides you with more than 170 integrations out-of-the-box and enables you to build custom integrations directly on its infrastructure.

Embedded iPaaS is not the only option

Building integrations fast, reducing maintenance and being able to build exactly the integrations your customers need are great goals for product integrations.

While embedded iPaaS can work well for some use-cases, there are also great alternatives available if you are looking to build product integrations in your SaaS.

If you are still unsure which solution is best for you, check out the Nango Slack community for recommendations. It has over 1,300 developers and product managers building integrations for B2B SaaS products.

‍