Today, the average enterprise uses over 1200 cloud apps. If you’re a B2B SaaS company, your customers have probably asked if your product integrates with the other cloud applications they use. These days, providing native third-party software-as-a-service (SaaS) integrations is table stakes for B2B software companies. Not only do these integrations play a huge role in your customers’ buying decisions when picking between SaaS platforms, they’re a lever that makes your product stickier as they enable your app to integrate seamlessly with their existing software. In fact, integrations have a direct impact on revenue - a Profitwell study demonstrated that products that support at least one integration have up to 15% higher retention, and up to 30% higher willingness to pay among customers.
Customers shouldn't have to export and import CSVs, or pay to build and maintain their own Zapier flows.
Sure, you can rely on services like Zapier or import and export CSVs, but providing high-quality integrations to your customers requires a deeply embedded, frictionless experience. The main question is whether you should build native integrations in-house, or use a third-party embedded integration platform as a service (embedded iPaaS) that provides access to dozens of integrations with a single connector, and handles all the the differences between each vendor’s API and authentication methods, manages user app credentials, and provides the UI for your customers to activate, manage, and configure their integrations.
As you evaluate options, you’ll find that there are benefits and drawbacks to both options for embedding native SaaS integrations, but if you’re looking for a scalable solution for your integration roadmap with much lower maintenance costs, using a pre-built embedded iPaaS solution will almost always be the better choice. Although it’s true that some solutions may not provide as much flexibility in comparison to developing the integration workflows in-house, the right integration solution will provide 95% of your use cases out of the box while still offering the flexibility you need to meet your customers’ needs and requirements, such as custom objects and access to all API endpoints.
If you’re reading this guide you probably already recognize the benefits and importance of providing native SaaS integrations. However, to further illustrate a few benefits, consider a scenario where your customers’ sales team needs a way to manage leads based on data that’s stored in your app. As leads move through their sales funnel, they may want to store that activity and corresponding notes within your app.
The siloed customer experience
To handle this, they could export the leads into a CSV and import it into your platform, (and do the reverse for bi-directional data sharing), but that creates an extremely repetitive and tedious process that results in enormous points of friction to using your app. The alternative could be using an external service like Zapier, but that forces your customers to manually build workflows themselves, and pay for an additional service in order to use your app in the way that they originally intended. This can severely increase the friction and prevent users that are trialing your product from getting to the ‘Aha’ moment, which reduces their likelihood of converting into paying customers.
The integrated customer experience
The other option, of course, is providing native integrations such that data in your app syncs directly with other apps. In our previous example, this may be with popular sales and marketing platforms such as Hubspot, Salesforce, or Intercom. Once a user enables an integration between your app and their other tools, it becomes an integrated part of their workflow, and thus makes it much more difficult for them to switch from your product to an alternative. Additionally, you can capture more value from customers who are often willing to pay more for a seamless native integration experience, which helps you unlock additional revenue streams through upsell opportunities.
Native integrations remove friction, increase switching costs, and can help you capture more value.
However, despite the obvious benefits of providing native integrations to your customers, integrations are often de-prioritized and backlogged until they start directly hurting the business through churned customers or lost prospects. When considering when to prioritize shipping integrations, successful businesses often take a proactive approach before it’s too late, and in doing so need to make the decision of whether to build integrations in-house or leverage a third party embedded iPaaS solution. This guide will help you navigate this decision and identify the most efficient strategy for delivering and maintaining integrations for your customers.
As developers ourselves, we know the urge to build everything yourself rather than use ready-made, off-the-shelf solutions. Building apps from the ground up may have its benefits, but when it comes to integrations, it can also add significant complexity to your codebase and infrastructure, not to mention months to years of additional development and maintenance.
One factor that’s often under-considered is how critical and complex managing authorization can be - not only to protect your customers’ data, but for compliance as well.
In standard integrations, developers must first request permission from users to access their account via an authentication process (e.g. OAuth), and then receive authorization permissions from the user. If the user grants permission to your application, the third-party SaaS application returns an access token. Access tokens may be specific to certain functionality in each SaaS application, which can result in needing to store multiple access tokens throughout the user’s session, dozens if they’ve enabled multiple SaaS integrations.
To add to the complexities of access token management, your team will also need to work with expired tokens. Tokens are usually set with an expiration date, so you must determine if the token is expired before passing it to the SaaS API. This adds to the complexity of your code, because it must account for the management of expired tokens and requery for new ones seamlessly within the user’s workflow, if the current user token is no longer valid.
There’s probably no doubt that your development team is capable of building out a secure authorization process with data privacy at its core - it just takes time, which leads us to the largest drawback of building native integrations in-house.
When competing against the other priorities on your roadmap, such as shipping core product features, integrations often end in the backlog due to the sheer amount of engineering resources they usually require. Not to mention that most engineers don’t love spending hours combing through esoteric API docs and stitching together different vendor APIs. Not only is this painfully time-consuming, the knowledge gained is incredibly vendor-specific and provides no value beyond that specific integration. Each time you want to launch a new native integration for your customers, your team will need to completely re-learn each vendor’s API documentation just to build the new integration.
Within the past few years, there’s been a rise of developer-focused solutions that have abstracted away parts of the application stack and provided them as an embedded, off-the-shelf solution. For example, there’s Stripe for payments, Plaid for banking, and Segment for analytics.
These solutions have not only helped engineering teams save thousands of hours and avoid reinventing the wheel, they’ve also helped bridge the gap between engineering and non-engineering teams. For example, Segment made it significantly easier to track customer data and analytics by providing an easy-to-use interface for non-technical business users to connect analytics data into new destinations.
Recently, this same concept has been brought to native SaaS integrations, with embedded iPaaS solutions providing a simple, unified abstraction over hundreds of third-party APIs that can save engineering teams thousands of hours. Using an embedded iPaaS solution helps avoid the significant cost, time, and risks that come with building and maintaining your own in-house integrations.
Build integrations faster
As you might expect, the first and primary benefit is the reduction in development time, cost, and resources. With an embedded iPaaS solution, the initial implementation simply requires you to add a single SDK to your app with a few lines of code. Thereafter, your team can easily ‘switch on’ new integrations using the iPaaS’s pre-built connectors - with little to no additional code. Moreover, an embedded iPaaS solution provides fully managed authentication, completely obviating the need for your team to learn and handle complex, vendor-specific authentication methods.
With any native integration, you’ll also need to provide a seamless user experience for your customers to consume the integration from within your app. An embedded iPaaS solution can also provide a ready-made user interface that you can easily embed into your app for your customers to seamlessly activate, manage, and configure their integrations.
The next time a prospect requests an integration you don’t support yet, you can use the iPaaS solution to deliver the requested integration within days or less.
Building and maintaining a comprehensive suite of integrations in-house can take many years - this is where you’ll see the true long-term benefit of leveraging an embedded iPaaS solution, which makes it possible to deliver new integrations within just a few days. Not only does this save your development team many months, if not years, it also strategically positions your organization to respond more swiftly to customer demand. The next time a prospect requests an integration you don’t support yet, you can use the iPaaS solution to deliver the requested integration within days or less, allowing you to close more customers quickly and accelerate your sales cycle without placing strain on your engineering team.
Visual Abstraction Layer - Workflow Builders
Certain embedded iPaaS platforms, like Paragon, provide a visual abstraction layer on top of the third-party SaaS APIs. This eliminates the need for your team to learn the nuances and complexities of each vendor’s API documentation, which can be a very time-consuming process. Using a provider’s GUI enables your team to build integrations more rapidly and easily, eliminating the need to learn or interface directly with each vendor’s API. This even makes it accessible to non-technical business users to create and manage integrations without engineering support.
Similar to services like Segment, your engineering team only needs to set up and define your in-app events once with the SDK, after which those events can then be reused and mapped into any number of different third-party apps.
The screenshot below demonstrates an example of Paragon’s workflow builder for a native Salesforce integration:
The workflow shown in this example maps new contacts created in your app to leads in your customers’ Salesforce CRM. The workflow is triggered by a “Contact Created” event sent from your app, and because the workflow editor provides a visual interface on top of the Salesforce API, you can easily define how data should map from your app’s contacts to your customers’ Salesforce leads without writing a single line of code or even reading Salesforce’s API documentation.
You’ll notice that the .event() request which triggers the “Contact Created” event is preceded by a call to paragon.authenticate(). This acts as the single point of authentication between users of your app and any third-party integrations they’ve enabled.
Building the same workflow in-house
Typically, you’d need to implement the vendor-specific authentication methods for each of the apps you’ve integrated with, in addition to storing and managing your user’s authentication credentials in your applications’ server and database. Then, when sending events to the third-party application API, you’d need to retrieve the relevant user credentials, ensure they’re valid, and refresh them if they’ve expired. Furthermore, each API might handle this process slightly differently, so you’d likely need to build and maintain separate libraries for each integration.
With .authenticate() and .event() in the example above, these challenges and complexities are reduced to two simple lines of code. Regardless of whether you’re providing one integration or one hundred, this remains exactly the same. Your team no longer needs to build hundreds of libraries and functional code to integrate with each vendor’s API - once you’ve implemented the SDK in your app, your team can enable new integrations within minutes.
Data privacy and security is a requirement when it comes to handling your customers’ data, which leads us to one of the final benefits - offloading the management of your customer’s third-party app credentials to an embedded iPaaS solution. Any misuse of user app credentials could result in data disclosure and potential compliance liabilities, but this challenge is solved with a solution that provides a fully managed authentication layer. Rather than bearing the security and compliance risks of storing your customers’ and managing your customers’ third-party app credentials, partnering with an embedded iPaaS provider like Paragon allows you to offload that responsibility to a trusted provider with specialized infrastructure and data security practices designed specifically for this purpose.
Although most iPaaS providers do not come with a pre-built user interface, certain platforms such as Paragon makes it possible to eliminate the costly design, product, and engineering work involved with building an seamless integration UX by providing an out-of-the-box user interface.
The Connect Portal is a customizable component that can be embedded into your application UI to provide your customers with a seamless, self-serve experience for activating, configuring, and managing their integrations. Not only does the Connect Portal allow your customers to authenticate their third-party app accounts with your app, it also provides a pre-built UI for your customers to configure the integrations - for example, your customers might want to define their custom mapping for how data syncs from your app into Salesforce.
Here’s an example from one of our customers, QuantCopy, who built their Salesforce integration with Paragon.
While building in-house and buying a third-party embedded iPaaS solution are both viable options when it comes to delivering native integrations for your customers, we hope that this article has provided clarity on both the benefits and drawbacks of each solution. To summarize and simplify the considerations, you can refer to the table below that compares the two side by side.
With new SaaS providers cropping up every day, we can reasonably expect that the average number of SaaS apps that companies use will continue to grow. As the SaaS ecosystem expands, it has become a necessity for B2B software vendors to have a comprehensive, scalable strategy for integrating their product with the other apps their customers use.
However, delivering integrations shouldn’t come at the expense of months or years of valuable engineering resources that would be better spent building your core product. There will always be tradeoffs of building integrations in-house vs. leveraging a third-party iPaaS provider such as Paragon, although for most companies, working with an experienced integration partner will typically save months of development time and hundreds of thousands of dollars in development costs.
1: Patrick Campbell - Profitwell Integration Benchmarks [online] available at https://www.profitwell.com/integration-benchmarks (Accessed January 2021)