Having support for a wide breadth of integrations has become key for companies to remain competitive and you’d be hard-pressed to find a modern-day B2B SaaS tool that doesn’t brag about the number of customer-facing integrations they support. Not to mention, there are a whole host of benefits that come with building integrations.

But how are companies developing and maintaining such a vast number of user-facing integrations? For many, the answer is by using an embedded integrations platform, also known as an embedded iPaaS. Embedded integrations platforms are designed to help you rapidly scale the number of customer-facing integrations your product supports by abstracting away some of the many difficulties that come with building integrations.

But what exactly are embedded integration platforms and how do they work? In this article, we’ll dive into this question and explore common types of embedded iPaaSes.

What is an Embedded Integrations Platform

I’m going to assume you’re familiar with what a customer-facing integration is. If you’re not, no worries, you can take a second to read our article on what native integrations are.

An integrations platform, or integrations platform as a service (iPaaS), is a SaaS designed to help you build integrations. An embedded integrations platform then, is an integrations platform that is embedded directly into your product. Since embedded integration platforms live inside of your product, they help you build customer-facing integrations (integrations where your customer connects their SaaS tool to your product). This is different from products like Zapier which is designed to help you hook your own company's SaaS tools together (e.g., to help you automatically repost your Facebook content on Twitter). When you hear the term “embedded integrations” it’s safe to assume that means the same thing as “customer-facing integrations”.

Characteristics

Embedded integration platforms help you build customer-facing integrations by abstracting away parts of the integration-building process. We consider these “table-stakes” features and any major platform will provide them. These include:

• ‍Auth Component: Some drap-and-drop SDK or Client component that your developers can add to the front end of your product. This component is responsible for allowing your users to authorize you to access their data. By handling the auth UI for you, this component removes the need for you to handle the different authentication methods of various integrations. Here’s what ours looks like when connecting to Salesforce for example

• API Abstraction: A way to make calling the integration’s APIs easier. Embedded integration platforms solve this problem in a variety of ways but here are two examples:
• #> A no-code UI workflow builder where you compose API building blocks (called ‘actions’) together that under the hood make API calls to the downstream integration on your behalf.
• #> A unified API that provides a standard schema and interface for a category of integrations (like Dialers). This means your developers don’t need to know that Salesforce calls deals “Opportunities” and HubSpot calls them “Deals”.

Types of Embedded Integration Platforms

If you’re new to the space, you’ve likely only heard of no-code workflow solutions like Workato. But these types of companies are only one type of embedded integration platform. In recent years, the embedded integrations space has exploded with newer ways to build customer-facing integrations. There are a few different types of integration platforms but we’ll focus on the two most common.

Workflow Integration Platforms

Workflow integration platforms model integrations as “workflows” wherein each step in the integrations process is a block that executes some ‘action’.

Here’s how you would build a customer-facing integration using a workflow platform:

• Add their embedded integrations marketplace or other auth component to your application’s front end.

• In a no-code editor, use the building blocks that the platform provides to put together a workflow that does something with the integration data.
• #> E.g., Use an action to grab all of the Contacts in the user’s Salesforce and then chain it with another action to call one of your APIs with those Contacts as the payload so we can save them to a database.

• Trigger that workflow, either by making an API call from within your product to

Pros

• Low-code: Workflows are built via drag and drop.
• Non-technical folks can often build and edit workflows (though an engineer still needs to write the code to call the workflow).
• Platforms often have support for a large breadth of integrations.

Cons

• These platforms were originally designed for non-technical users rather than developers which results in limited flexibility and differs from the work-streams a developer is used to.
• If the platform doesn’t have a feature or integration you need, you will be blocked and need to either build a native integration in-house or pay for expensive add-ons to get a new integration live.
• Hard to scale: Each workflow represents exactly one use case such as creating a contact in Salesforce. Supporting many integrations can result in maintaining hundreds of individual workflows which can be a tremendous burden on your team and nearly impossible to debug.

Native Integration Platforms

Native integrations platforms don’t use workflows and instead provide tools and APIs for building customer-facing integrations directly in your code (i.e., natively).

Here’s how you would build a customer-facing integration using a native platform:

• Add the embedded integrations component, usually through a client-SDK, to your application’s front end.

• Find the endpoints on the native integration platforms documentation that you need to call and call them from within your code.
• For example, if you’re building CRM integrations and the platform supports a unified API, you might call the api/crm/contacts endpoint in your code when a new user creates an account in your product to get that users contacts. Here’s an example of one of our endpoints.

‍

‍

Pros

• It’s possible to build significantly deeper integrations since you have access to all of the capabilities of the downstream system (not just what’s supported by an ‘action’).
• #> You can also optimize your integrations for speed or security in ways that you can’t with workflow solutions by choosing exactly what APIs are called.
• You’re not blocked on the platform to add functionality since you always have direct access to the downstream integration’s APIs.
• Built specifically for developers and have a significantly better developer experience through strongly typed SDKs.

Cons

• Since everything is done in-code, it must be maintained completely by developers.
• Since these platforms are newer, they don’t have support for as many integrations.

What is Vessel?

When my co-founder and I started building integrations at the beginning of our careers, the only options we had were workflow solutions which we found to be too limiting to build anything sophisticated.

That’s why we started Vessel, the most powerful native integrations platform to ever exist. Our vision for Vessel is to build the embedded integrations platform we always wanted; one that can actually handle all of the use cases you have when building user-facing integrations, from ETL to making real-time requests at scale.

With Vessel, you’re not limited by a unified API or a clunky no-code UI, we give you all of the infrastructure and interfaces you need to build the deepest and feature-rich integrations possible all while significantly reducing the time it takes you to build them.

If you’re interested in learning more, don’t hesitate to reach out at zach@vessel.dev!