The SaaS space is rapidly expanding, with some 25,000 companies worldwide and new ones starting daily.
And the apps created by these companies need integrations. With an average company today using 125 SaaS apps, SaaS customers expect that integrations will be part of the functionality provided by those apps.
In addition, we have many thousands of legacy or on-premise software products that also need integrations, whether with SaaS apps or other non-SaaS apps.
These integrations could be created in different ways, but an increasing number of them will be third-party integrations.
What are third-party integrations?
A third-party integration is a connection between two or more apps that uses a third-party platform for essential integration functionality. Enterprise iPaaS, embedded iPaaS, and unified APIs are examples of third-party platforms.
This definition of a third-party integration is what we use. But, to prevent any confusion, we must note that this is not the only definition you'll see for third-party integrations. Another definition considers third-party integrations as any integrations between your app and a different app (one that isn't yours). In this definition, the third-party is an app, not the platform used to enable the integration.
Under this definition, nearly all integrations would be third-party integrations, so we don't find it very helpful.
Third-party integrations vs native integrations
We've just noted that a third-party integration uses a third-party platform. But a native integration extends an app so that users cannot tell where the app stops and the integration starts.
Some vendors define native integrations as only those built in or on your app using your internal development resources.
But from your customers' perspectives, the tools and platforms you use for the integrations they need with your product are unimportant as long as those integrations function as first-class features of your app. As a result, many third-party integrations are also classed as native integrations.
That said, some native integrations are built from scratch without a platform. In addition, some third-party integrations can be so obviously different in accessibility, UI, and UX from the app they serve that they are not native integrations.
While we there is much overlap between third-party integrations and native integrations, those terms are not congruent.
Examples of third-party integrations
Example 1 – You are an individual user, and you have an accounting system that you use for special projects. However, you need that accounting system to be integrated with the project management/tracking system you also use to track costs by project and project phase.
Using a tool like Zapier for general workflow automation probably makes the most sense for this third-party integration example, as long as the platform has the connectors for your accounting system and your project management/tracking system.
Example 2 – Your company ERP needs to get data from all over the enterprise: accounting, sales, support, R&D, etc. You'll need integrations from dozens of apps to your ERP. In some cases, the data will require a one-way sync. In other cases, you may need to set up a two-way sync.
The key for this example is that you are providing third-party integrations that are internal to your company. Therefore, an enterprise iPaaS is the right platform.
Example 3 – You work at a SaaS company and your app is a manufacturing maintenance scheduling system. One hundred fifty companies use your app to schedule downtime and non-downtime maintenance for their manufacturing facilities. Each customer needs to send this maintenance scheduling data to its ERP. And, while your customers don't all use the same ERP system, they collectively use about 20 common ERPs.
The key here is that you need to build a bunch of third-party integrations that are nearly identical (same data) to several ERP systems. If the 20 ERP systems are all included in a unified API and the API covers the data you need to transfer, the unified API is probably the right platform for this example.
Example 4 – Hundreds of customers use your SaaS app (a highly specialized fixed asset depreciation tool). Each customer has its own accounting system, with several being custom-built systems that have been around for decades. Your customers need your app to exchange data with those accounting systems, as well as other non-accounting apps. In addition, your customers will need a range of unique configurations.
The key here is that you must create third-party integrations to many different systems, some of which are custom. And these integrations need to be developed for your customers, making them external SaaS integrations. You'll need the flexibility of an embedded iPaaS to build the third-party integrations you need for this example.
Types of third-party integration platforms
We've already mentioned the third-party integration platforms in the above examples, but here they are again:
- Workflow automation
- Enterprise iPaaS
- Unified API
- Embedded iPaaS
Let's look at each in turn and how they enable third-party integrations and the teams that build them.
Third-party integrations via workflow automation
While this broader term could encompass all the other categories, it can also be a category in itself. Tools such as Zapier fit this category better than any other. Zapier is a platform that can be used for third-party integrations inside and outside the enterprise but is primarily the choice of individuals who need to integrate common apps from their desktops.
Because Zapier makes it clear to users that its integrations depend on Zapier (because the user is a Zapier user, not a user of SaaS product X), this integration platform allows users to build third-party integrations. But we would not classify these integrations as native integrations.
Third-party integrations via an enterprise iPaaS
Many companies use enterprise iPaaS (integration platform as a service) to build internal third-party integrations. Enterprise iPaaS platforms include standard API connectors to many common SaaS apps, allowing developers and non-developers to create internal third-party integrations more quickly than traditional coding from scratch.
While all integrations built with an enterprise iPaaS are qualified as third-party integrations, only some may be classified as native integrations. In many cases, the integrations between internal apps are quite obviously separate from the apps they connect, meaning that these are not native integrations.
Third-party integrations via a unified API
A unified API combines access to multiple APIs within a software category (such as HRIS or ATS). This API abstracts the complexity of connecting to many systems into a single set of rules for connecting to one API, thereby simplifying the process of building third-party integrations with those systems. As with embedded iPaaS, a unified API allows developers to create integrations more quickly than if using the traditional approach.
Integrations built with a unified API are classified as third-party integrations, but many of them are not native integrations because they do not blend seamlessly into the apps they connect.
Third-party integrations via an embedded iPaaS
A B2B SaaS company can use embedded iPaaS to create third-party external integrations – integrations between a SaaS product and the other apps their customers use. These platforms include standard API connectors for common SaaS apps, streamlining the integration build process.
Embedded iPaaS is optimized for working with third-party integrations, ensuring that the integrations and associated processes will properly scale with customer growth.
Unlike unified APIs, embedded iPaaS supports the configurability and complexity required to build integrations with all applications your customers use, regardless of your market vertical. In addition to the low-code integration designer, an embedded iPaaS allows developers to write code when new functionality is needed.
Integrations built with an embedded iPaaS are third-party integrations and native integrations. They are third-party because they use an embedded iPaaS (integration platform as a service). They are native because the embedded iPaaS allows SaaS teams to change colors and fonts to match a product's branding or even build a fully custom integration marketplace via an SDK and API to control the third-party integration UI down to the smallest detail.
Benefits of 3rd-party integrations
Most software integrations used to be coded by hand by the same dev teams that built the corresponding software. While some software vendors still do things traditionally, many are taking advantage of the third-party integration platforms available today.
Since we are an embedded iPaaS, let's look at the benefits you and your teams would receive if you used an embedded iPaaS for your customer-facing integrations.
Save dev time
Building third-party integrations for B2B SaaS customers using an embedded iPaaS provides substantial time savings over other approaches.
An embedded iPaaS includes a low-code integration designer, a library of built-in components, an integration marketplace, an embedded workflow designer, integration deployment and support tools, and a cloud-native infrastructure – absolutely everything needed to build, deploy, and support customer integrations successfully. SaaS teams report dev time savings of up to 80% after implementing an embedded iPaaS.
Increase win rate and sales velocity
An embedded iPaaS allows your team to create reusable, configurable third-party integrations in days or weeks instead of months. Doing so lets you say "Yes" more often when a third-party integration is what your prospects need to become customers. Based on the quick dev turnaround supported by an embedded iPaaS, you can frequently include new third-party integrations with customer onboarding.
Customers often want your product to do X, even if X wouldn't necessarily be helpful for your overall product direction. Third-party integrations may allow you to offset these functional gaps by giving customers different ways to solve those business needs.
Provide a terrific UX for integrations
When you create third-party integrations for your customers with an embedded iPaaS, you ensure that those customers will have a first-class integration experience.
Further, your customers won't suffer from the classic black-box integration experience, where they rely entirely on your support and dev teams to tell them what is happening with that integration. Instead, customers can enable, configure, and even support their own third-party integrations because they have detailed access to integration configuration, status, log, and alerting data.
Change is a constant, and an embedded iPaaS makes it easy to make needed changes to integrations as you manage and version the underlying code within your standard CI/CD processes.
Improve your customer service
When you use an embedded iPaaS for third-party integrations, they run on a purpose-built infrastructure with redundancy, scalability, and security built in. This greatly reduces performance issues and other problems that can occur with integrations.
Since no time is spent on infrastructure issues, your support team can focus on the third-party integrations themselves. This is where the deployment and support features of the embedded iPaaS show their value. You can empower your non-devs to do much of the support traditionally handled by devs.
You can also set up your customers to self-service their third-party integrations, allowing them to resolve many minor issues immediately. Customers can view, configure, monitor, and otherwise directly interact with their integrations without waiting on your support teams for first-level support.
Reduce customer churn
Using an embedded integration platform for your customers' third-party integrations can help reduce customer churn by making your product essential to your customers because it's a hub for their other critical apps. The platform can elevate third-party integrations in visibility and value, establishing them as key product differentiators.
For customers, leaving your product with its third-party integrations means removing your app and losing an essential piece of their business workflow automation. Finding another vendor to replace your app plus its integrations drives up the cost of switching, thereby decreasing the probability of churn.
For everything there is a season
There was a time when building integrations from scratch was the only way to go. It was time-consuming, expensive, and took devs away from more critical tasks, but that was how integrations were built.
Now, using a integration platform to build third-party integrations is the right choice in most scenarios. Using the proper integration platform can save you time, money, and your devs' sanity.
If you need to build integrations between your SaaS product and the other apps your customers use, schedule a demo, and we'll show you how Prismatic can supercharge your approach to delivering those integrations.
