The Engineer’s Guide to Embedded iPaaS and Unified APIs

This need for integration in our applications has spawned two different styles of integration platforms - Embedded iPaaS and Unified APIs - both of which provide apparently similar features and functionality.

From the perspective of a software engineer, however, the way to use and implement the two approaches can be very different. Making an effective choice between Embedded iPaaS and Unified APIs as an engineer means unpacking their key features and then understanding how that might impact how you do your job effectively.

What is Embedded iPaaS?

Embedded iPaaS (Integration Platform as a Service) is an integration style that has grown in significance over several years. It offers the means to create complex, multi-step workflows that can be initiated from your application code using an SDK or API. Embedded iPaaS platforms are cloud-based and offer a suite of "connectors" that provide the means to listen to or invoke actions at a cloud-based SaaS platform. Examples of connectors in Embedded iPaaS platforms include adding a contact in Salesforce, adding a new employee to BambooHR, listening for new orders on Shopify, and so on.

The "Embedded" in Embedded iPaaS refers to the key difference with traditional iPaaS platforms, namely that workflows can be bundled with your application and executed by your customer. Depending on your use case customers can authenticate at, for example, their Salesforce instance using your application, authorize access, and then use your application together with the workflows you've bundled with it. This may sound trivial, but the means to create complex multi-step workflows.

The Embedded iPaaS Developer Experience

Embedded iPaaS is, however, also typified by the use of low- and no-code development tools, with visual integration builders that provide a canvas view of the connectors. This view allows developers to rapidly "stitch" connectors together to create workflows, with configuration dialogs to add the relevant parameters to each connector. The tooling is intended to be so simple that non-developers can use it, broadening the development team to roles like business analysts who cannot code but do understand integration requirements.

An example of using connectors in Paragon

For non-developers Embedded iPaaS can therefore sound like all upside. You get a simple, easy-to-use development tool to create workflows you can then bundle and reuse across your application users. This view, however, does not always sit well with software engineers who like the control and familiarity their programming language of choice gives them, and the frameworks and tools they already use. Integrating Embedded iPaaS into your software development lifecycle can also take time and effort, especially when you are mixing your existing test framework and Continuous Integration approach with the tooling offered by the Embedded iPaaS vendor. You may also not be able to take advantage of the provider's SDKs if none is available in your programming language of choice. You can still integrate with their APIs, of course, but this will obviously add to your development effort.

Why use Unified APIs?

Unified APIs are the other integration style that has become increasingly popular as integration needs have become so important. The premise is largely the same as Embedded iPaaS, namely to allow consumers to access SaaS provider platforms using pre-built connectors. Unified APIs are, however, built the same way as a regular API, providing operations available over HTTPS that invoke operations at the provider APIs. The key difference is that Unified API connectors have a one-to-many relationship between the API you call at the Unified API provider and the APIs invoked at the provider APIs. You can therefore use one connector at Apideck to consume, for example, approximately 50 different human resource platform APIs.

This aggregation feature of Unified APIs is one of its key features for organizations. Software engineers can create one integration to many functionally similar platforms, saving significant time and resources on development. They also reap the benefit of managed upgrades, which are taken care of by the Unified API provider. Configuration of the connectors to different providers is also straightforward and typically facilitated by dashboards like the one shown below.

The Apideck dashboard that shows configuring the BambooHR connector

Finally, software engineers can also implement workflow as they see fit, as they can reliably call atomic operations at the Unified API and act on the result accordingly. This provides a great deal of flexibility in their control flow, which may not be matched by that available through the more restrictive integration builder at an Embedded iPaaS platform.

The Unified API Developer Experience

The Unified API developer experience is very similar to consuming a regular API, and it is likely to be a much more natural experience for software engineers used to integrating with APIs. They can still use the same programming language, tools, and frameworks they use whilst reaping the benefits of accessing many providers using one API client.

You may, of course, also have a role for "non-developers" in creating integration workflows. This is a non-starter in the Unified API world as it stands, as this integration style is not well-served by appropriate tooling. If you are keen for non-developers to create integration workflows, but feel that Embedded iPaaS is not the right fit then you may need to find other integration tooling that facilitates their needs.

Choosing Based on Developer Experience

Choosing between Embedded iPaaS and Unified APIs as a software engineer may initially seem straightforward.

If you are a fan of simple integrations and want to integrate with native web APIs, control your workflow in code, and use your API client library of choice then Unified APIs make sense. You can code as you normally do but still take advantage of the key selling point of a Unified API, namely that you can access many platforms that serve the same function through one integration. Your control flow and error handling fit neatly with your existing practices and patterns.

To use Embedded iPaaS effectively you will need to be comfortable with low- or no-code development, which may be an environment that is very unfamiliar to you as a "traditional" engineer. It may take time to grasp this approach based on your existing mental model, and the paradigm can feel alien for many developers who use traditional programming languages. You'll also need to follow the guidance from the Embedded iPaaS vendor on aspects you find simple using your existing language and framework, such as unit testing and Continuous Integration.

Final Thoughts

The pros and cons of using Embedded iPaaS versus Unified APIs are therefore more nuanced than you may think. Where you lose out in one aspect, you may benefit in another. Take time to investigate and trial the features across different providers of each type of integration platform. This will help you make the right choice for your long-term success in orchestrating workflows with multiple platforms and providers.