Embedded iPaaS vs Unified API

If you're trying to scale your SaaS app's integration roadmap and ecosystem, you've probably come across Unified APIs and Embedded iPaaS. These are the two emerging solution types that  B2B SaaS engineering teams are adopting to streamline the native integration development and maintenance processes for their apps. That said, they approach solving the challenges of working with 3rd party APIs differently, each with their own advantages and drawbacks, and we're going to dive into some of those differences in this article.

But in case you're unfamiliar, let's start with a quick overview on Unified APIs and Embedded iPaaS.

What are Unified APIs?

Unified APIs provide a single API for multiple integrations within the same category. These APIs offer a standardized approach to accessing various 3rd party APIs - for example, a unified CRM API standardizes the schema of Salesforce, HubSpot, Pipedrive, and other CRMs.

By using a unified API, developers can avoid building and maintaining native integrations separately for each service, which could theoretically enable you to ship integrations 10x faster (assuming the unified API provider supports the integrations you need)

Here are the primary features that you'll get with a unified API provider:

1. Embedded Experience: With their SDKs, you can provide an out-of-the-box integration experience to your users where they can authenticate their 3rd party accounts.

2. Managed Authentication: Unified APIs provide fully managed authentication for the supported integrations.

3. Category-based Unified APIs: All providers generally provide a few Unified APIs, one per category such as CRMs, Accounting, or Task Management. This allows developers to leverage the benefits of a unified approach across various services.

4. Monitoring: Unified APIs provide logs of the requests that you make to their APIs, as well as the requests that their API then passes onto the underlying 3rd party service.

Now, onto embedded iPaaS.

What are Embedded iPaaS?

Embedded iPaaS are workflow-based solutions that allow developers to easily integrate 3rd party services into their applications with pre-built integration connectors and a visual workflow builder.

Unlike traditional iPaaS solutions, embedded iPaaS are focused explicitly on the native integration use case, which means that your users will not need to author the integration logic themselves (although some iPaaS solutions like Tray/Workato have tried to build secondary 'embedded' products as well).

Here are the primary features that you'll get with an Embedded iPaaS:

1. Managed Authentication: Similar to Unified APIs, embedded iPaaS solutions provide fully managed authentication for the supported integrations.

2. Visual Workflow Builder: Embedded iPaaS solutions come with a visual workflow builder that allows developers to easily define the business logic needed for each integration.

3. Webhooks triggers: Workflows can be triggered from webhooks, which enable you to provide real-time integration use cases

4. Serverless infrastructure: Embedded iPaaS solutions provide a serverless infrastructure that handles all requests to the 3rd party API as well as your API

5. Task History: Logs in embedded iPaaS show details of each workflow run, making it easier to track and troubleshoot any issues.

TL;DR of navigating the decision:

Now let's talk about how you should approach deciding which type of solution to adopt (before you even get into the details of comparing individual vendors).

Picking a platform to build your native integrations on is a long term strategic decision, so you want to make sure it's relatively future proof, so let's cover all the potential deal breakers that can simplify simplify the decision (both product & engineering should discuss this together).

Ask yourselves - do you need any of the following?

1. Integration-specific features/endpoints: Will any of your integrations require interacting with specific features that only one (or a subset) of the 3rd party applications in a given category have?

2. Webhooks for real-time use cases: Will any of your integrations need to support real-time behavior?

3. Custom integrations not supported by the vendor: Do you need to build integrations that aren't supported out-of-the-box by the vendor?

4. Users with strict security requirements: Are your users worried about providing unnecessary access to data in their 3rd party applications?

5. Serverless integration infrastructure: Do you need a scalable serverless infrastructure for handling concurrent and/or a high volume of requests for the integrations?

If any of the above are a must-have, then a unified API likely won't be the right solution for you team - only an embedded iPaaS can support your requirements.

However, if you none of those are key requirements, then you may be able to ship faster with a unified API given the one-to-many benefit.

Benefits and drawbacks of Unified APIs

While we dive into the benefits and drawbacks of unified APIs in much more detail in this article, here’s the high level of what you need to know.

Pros

Fully managed authentication

For integrations that they support, supported integrations: Unified APIs handle authentication for the supported integrations, relieving developers from the burden of managing authentication individually for each service. This saves time and effort.

Build once, ship many

For basic integrations, the ability to define the integration logic once for a category and instantly provide multiple integrations can be a huge timesaver for engineers. This streamlines the development process and accelerates the shipping of multiple integrations.

Maintained API references

The unified API provider is responsible for maintaining references between their unified API schema each underlying API - as such, when a 3rd party application releases a breaking change, your engineering team won’t have to worry about updating the integration.

Cons:

Limited API endpoint coverage

Unified APIs can be very limiting when it comes to coverage of the underlying APIs’ endpoints and objects, due to the nature of a unified model (lowest common denominator between APIs). This means that your dev team will not be able to access many of the features and functionality offered by each individual API, and can only build extremely simple use cases within each category.

No integration-specific logic

As mentioned earlier, if you want to build unique integration functionality for a specific integration, that will not be possible with a unified API.

Minimal support for webhooks

Most unified APIs only support CRON based updates, which means that updates occur on a set cadence (ie. every hour) vs. in real time when an event occurs in a 3rd party application. This restriction can hinder the implementation of integrations that require immediate or near real-time data updates.

Lower rate limits

In order to avoid hitting rate limits for any particular API, Unified APIs may impose the lowest rate limit possible from the underlying providers, which can impact performance and scalability across enterprise products. For example, whilst an SMB integration can get by with low rate limits, an enterprise integration with products like Oracle or Salesforce will get severely limited by lower rate limits.

Security challenges

Unified APIs generally request all scopes vs. what’s minimally required for a given use case, because they can’t support integration-specific scopes. This can be a cause for concern for your users as they may not want to provide access to data that is not necessary for their use case.

Schema aggregation

Unified APIs are opinionated in that the teams behind them determine how objects and fields from one application should correlate to another. If you don’t agree with how they’ve mapped the underlying APIs, you will unfortunately be stuck.

Cloud Only

If your customers have strict requirements around their data and you need to manage all of their data in your own infrastructure, unified APIs may not be an option. All of your customers’ integration data will inevitably go through their API before it reaches the underlying 3rd party API.

Benefits and drawbacks of Embedded iPaaS

Now let’s get into the details of the advantages and potential limitations of using an embedded iPaaS for your product’s integrations.

Pros:

Fully managed authentication

Similar to unified APIs, embedded iPaaS solutions provide fully managed authentication for supported integrations (and in Paragon’s case, even for custom integrations). Scopes are defined at an individual integration level, so you will never need to request more scopes than necessary.

Pre-built API connectors

Embedded iPaaS solutions offer pre-built connectors that abstract the complexities of understanding and working with each individual third-party APIs. The visual workflow builder allows developers to easily define integration logic by visually connecting different services and workflows, reducing the coding effort required.

Concurrency & Scale

Embedded iPaaS solutions provide a serverless architecture, enabling scalable and efficient request execution without the need for managing backend infrastructure. This allows developers to focus on integration logic rather than infrastructure management.

Highly observable runs

Observable workflows with detailed logging: The logging features in embedded iPaaS solutions provide insights into each workflow run, including detailed information about each step execution within the workflow. This makes it easier to track and troubleshoot any issues that may arise during the integration process.

Cons:

There is more variability within the Embedded iPaaS space, but the cons listed are still shared across most vendors in the space.

Not engineering native

Some engineers may not enjoy using a visual workflow builder, as it feels disjointed from the rest of their software development lifecycle. Additionally, most solutions do not offer robust release management and versioning controls, which can be risky as it becomes extremely easy to release changes into production.

Paragon is designed for and by developers, providing features that help it fit into the software development lifecycle for integrations. A few examples are our Releases, Users API, and monitoring features.

Limited connector coverage

No Embedded iPaaS solutions abstract away the entire underlying API, and as such, you may still need to do some research on non-frequently used API endpoints. Additionally, many do not provide easy access to the underlying API - in most cases, you would have to build and maintain your own, separate connector, to do so.

Paragon addresses this with our integration request step, which makes it easy to use authenticated calls to any 3rd party API endpoint.

White-labeling

Not all embedded iPaaS solutions offer the same level of white-labeling for the end-user (your customer) experience. For example, some solutions force you to use their marketplace UI, which can feel disjointed from your application.

Paragon provides more flexibility by enabling customers to build their own marketplaces, but an out-of-the-box config modal and also a headless implementation.

Here is a quick overview on which limitations Paragon addresses within the embedded iPaaS space.

Conclusion

As you can tell, unified APIs and embedded iPaaS solutions offer distinctly different approaches for streamlining native integrations development for SaaS applications.

Fundamentally, unified APIs sell a strong story on building a single integration and being able to deliver many at once. This can be a strong accelerator for extremely straightforward integration use cases. However, embedded iPaaS solutions are a significantly more future proof option. Not only will you be able to interact with the full breadth of each 3rd party API, you also save yourself from having to build an infrastructure that can handle concurrency, throttling and scale.

If you want to chat in more detail about your integration strategy and roadmap to help navigate this decision, feel free to book some time here!

‍