Introduction
As the SaaS ecosystem has matured, so have customers' expectations for native product integrations. Just a few years ago, B2B SaaS companies that offered native product integrations had a competitive advantage (think of Slack, HubSpot, etc.). But today, native integrations are table stakes for all SaaS buyers - check out the State of Integrations 2024 to get the stats. Customers expect interoperability between your product and the other tools they use, whether it be CRMs, accounting platforms, or any other SaaS tool in their stack. Not only do these native integrations play a huge role in your customers’ buying decisions when picking between SaaS platforms, they make your product stickier as well.
However, the engineering effort required to build and maintain native integrations is significant. Managing authentication for your users' integrations and navigating the challenges of working with every vendor's APIs is just the tip of the iceberg - there are many layers of complexity that come with building a scalable integration infrastructure for your product.
That's why many SaaS companies have adopted Embedded iPaaS platforms like Paragon to help streamline the integration development process, so they can keep up with customers' demands. But buying an embedded platform is never an easy decision, and as developers ourselves, we know the urge to build everything yourself rather than use ready-made, off-the-shelf solutions. That's why this guide will walk you through all the factors your engineering team needs to consider when making a build vs. buy decision for your native integration strategy.
Want a quick 2-minute overview of how an Embedded iPaaS works? Check out the product tour here.
In-House Native Integration Development
We’ll walk through the step by step process of building native integrations, and outline some of the benefits/challenges with each step as it pertains to building in-house.
Getting sandbox credentials
Before development can even begin, you’ll need to get a developer sandbox for the 3rd party app. Some apps make this easy by enabling anyone API access via a free trial, but often times you’ll have to go through partnerships to get access which can take weeks, if not months.
OAuth and Token Expiry
You will need to manage authentication in a multi-tenant environment for every integration, which is very complex especially when it comes to security and dealing with OAuth (the standard that is anything but standard). For all integrations that require authentication via OAuth, your developers will have to build mechanisms to handle each 3rd party app's unique implementation of the token refresh policies. Just as one example - some refresh tokens never expire, some expire after a certain number of days, while others may expire every time they are used.
As a result, you must account for the management of expired tokens (each with different sets of rules) and the re-authorization process to get new tokens before every API request it makes to the 3rd party APIs. Otherwise your integrations will be at risk of erroring out all the time which can have severe implications on your customers' operations.
Security
Beyond the complexities of getting the auth to work properly, you also need to ensure that your auth services are highly secure and penetration tested. If a malicious actor were to gain access to your customers' credentials or tokens, all their business critical data can be compromised.
We wrote a more in-depth article here about the challenges of handling authentication for native integrations.
Working with 3rd party SaaS APIs
Vendor specific knowledge
While working with 3rd party APIs is second nature for developers, in our experience, very few SaaS companies provide thoughtfully designed and documented APIs.
This is primarily because they are not developer tools by nature and do not put as much emphasis on the design of their APIs.
This can be very time-consuming, and the knowledge gained is incredibly vendor-specific and provides no value beyond that specific integration. So 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.
Feature updates
This also has implications beyond building the initial version of the integration. As your customers begin using an integration, they'll ask for additional functionality to be included, at which point your team will have to re-learn the 3rd party API (because it will have been months/years since they built v1).
Webhooks / Triggers
In order to receive and ingest data when updates occur on the 3rd party application, you’ll need to build webhook listeners and/or custom CRON jobs.
Two quick examples of this: ‘When a record is updated in my customer’s Salesforce account, update the synced record in their instance of our application’, or ‘When a new invoice is created in my customer’s Netsuite account, send a notification to their Slack.’
If the 3rd party service provides webhooks for the desired event (ie. invoice created), then you’ll need to ensure that your webhook listener stays functional. This is actually much more difficult than teams expect because when it fails, there is no error that’s thrown - the event data will simply stop coming in.
On top of that, depending on your integration use case, you may need to listen for updates on events that are not supported via webhooks by the 3rd party application. In those cases, you’ll need to build CRON based triggers (ie. ping the 3rd party endpoint and check for changes every 5 minutes).
End-user Experience & Customization
With native integrations, you need your business logic to be extensible enough to support nuances between your customers’ implementations of your application, the 3rd party application, or both.
For example, with sync use cases, your customers will want to have control over how data maps between your application and theirs, which will require you build field mapping functionality for the integration.
Even with something as simple as a Slack integration, you may want the ability for your customers to pick the channel they want notifications to go to (instead of forcing the creation of a new channel).
That said, when building in-house, you’ll have complete control over what that auth and configuration experience looks like.
Here’s an example of HubSpot’s Salesforce integration, which contains an incredibly sophisticated integration settings experience that may be very difficult to achieve with pre-built solutions.
Hubspot's Salesforce Integration Config
Resiliency/Error handling
Your customers will be building their business processes/workflows around these integrations, so you need to ensure that they are built reliably. This is common sense when building any product, but the additional dependency on the 3rd party API introduces significantly more complexity and risk.
To combat this, you need to write resilient, durable functions that can execute idempotently. This means building in auto-retry that can handle recoverable errors such as hitting an API rate limit, without replaying partial executions.
This leads nicely into the last piece - maintenance.
Integration maintenance
Once your team builds the integration, they need to maintain/update it in perpetuity.
3rd party API breaking changes
Your team will have to keep an eye on any breaking changes to the 3rd party API that are released, as they can break the integration. While this does not happen too frequently on a per integration basis, if you get to the scale of dozens of integrations, you may find yourself in a state of constantly having to update existing integrations on rotation.
Support and debugging
Chances are, you have on call engineers on rotation who will be tasked with debugging issues that come up with integrations, and they will be completely unfamiliar with the 3rd party application's API. So to limit your incidence response times, you’ll need to build internal documentation and runbooks to enable any of your engineers to debug integration issues when they come up.
Another thing to consider is that often times integration errors are a result of end-user configuration or authentication errors, vs. issues with the actual integration. So to further streamline your support process around integrations, you’ll need to equip your regular support team with the tools to parse between end-user error and errors that require engineering to get involved.
There are many ways that this can be implemented, but some prerequisites include:
Highly observable code and logs
Translating every 3rd party app’s errors into human readable errors
There’s a lot more that comes with maintaining integration in-house, and we wrote a more in-depth article you can read up on here.
Buying an Embedded Integration Platform
Now that we’ve covered, at a high level, what it’ll take to build a native integration in-house, let’s talk about the ‘buy’ option.
There has been a rise of developer-focused solutions that provide building blocks for app development in the form of embedded, off-the-shelf solutions. For example, there’s Stripe for payments, Plaid for banking integrations, and Sisense for embedded analytics. These solutions solve challenges around various mission-critical customer-facing features, enabling their customers to focus their engineering efforts on core competencies and differentiating features.
Embedded iPaaS solutions like Paragon take this concept and apply it towards native product integrations. By providing a serverless infrastructure that offloads many of the complexities around developing and maintaining native product integrations, your engineering team will only need to design the business logic for the integration.
Fully Managed Authentication
Embedded iPaaS platforms provide fully managed authentication on all API key based and OAuth integrations, and handle the nuances between how different services implement token expiry. Whether it be for the supported integrations in the catalog, or even Custom Integrations, you'll never have to deal with the challenges of ensuring your customers’ tokens are constantly refreshed and valid.
End-user experience
Embedded iPaaS platforms eliminate the costs of designing, developing, and maintaining the integration auth and configuration experience for your users by providing embeddable UI components.
These make it really easy to provide your users configuration options such as field mapping — features that would otherwise require a lot of engineering to build properly.
However, this can come at the tradeoff of complete control and customization of the integration UI, unless the Embedded iPaaS provides a custom UI/headless option.
Highly Observable Code
The workflow construct enforces best practices from a development perspective, as every part of the business logic for the integration is highly readable. Clear inputs and outputs are documented for every step execution, which makes it easy for your engineering team to test the integration and enables your support team to easily debug issues when errors occur.
The workflow construct also makes the integrations your team builds highly maintainable and free of tech debt so any engineer on your team can easily build upon the existing business logic (even if the original engineer who built the integration leaves the company).
Here's a quick tour of Paragon's workflow builder to give you a sense of the experience.
Paragon, the most developer-native embedded iPaaS, takes this a step further with an integrations-as-code framework called Paragraph that gives engineers access to all the benefits of workflows, in code. Here's a short tour on Paragraph.
Abstractions Over 3rd Party APIs
Instead of having your engineers spend weeks researching every 3rd party API you need to integrate with, they can leverage the abstractions Embedded iPaaS platforms provide over the 3rd party services’ APIs.
This saves them from needing to understand which endpoints they need to hit. Even when the 3rd party service releases a breaking change to their API, your team won't have to deal with updating any of the integrations as the integration platform maintains the underlying references for their abstractions.
However, not every endpoint will be abstracted - that’s why solutions like Paragon provide full parity to the 3rd party API so even the most niche use cases are supported.
Webhooks/Triggers
The abstractions span beyond just the 3rd party API endpoints as well. Webhook-based triggers are provided out of the box for the majority of pre-built integrations, and in cases where the 3rd party application doesn’t provide webhooks for the desired event, the platforms may provide CRON-based triggers as well.
This way, your team can simply pick the desired 3rd party event they want to use to trigger a workflow instead of solving the challenges around building performant webhook listeners.
Serverless Infrastructure
If you build integrations in-house (or are using a purely API-based solution), you are responsible for building and maintaining your own infrastructure. As your company grows and your integrations’ usage volume scales, your engineering team must constantly ensure that your infrastructure is capable of providing the availability and throughput required to support your customers and execute requests in real-time.
With Embedded iPaaS solutions, you would rely on the platform’s cloud-hosted infrastructure to perform. The ability for the hosted infrastructure to handle challenges like scale and concurrency will be platform-dependent, so if you have high scale requirements, make sure to do your diligence during the sales process.
Quick plug: At Paragon, it took years to build our workflow engine that can execute workflows with high concurrency and high-availability runtime and support the scale of enterprise SaaS companies (1B+ requests/month). Additionally, Paragon is the only solution that can be deployed on-premise on your own infrastructure, for stricter security requirements.
Support & Debugging
When customers flag issues with an integration, it could be caused by issues with your own product, with the 3rd party product, with the integration logic, or by end-user configuration errors.
Embedded iPaaS platforms like Paragon streamline the debugging and support experience by providing a suite of monitoring & observability tools, such as a log of workflow executions that surface where errors have occurred, and for which customers.
Some platforms take it even further, by providing a dashboard that shares a centralized view of each of your customer’s integration activity and configuration. This will enable your support team to handle any end-user driven errors, and prevent any non-technical issues to be triaged to your engineering team. Not only does this accelerate how quickly you can resolve customer issues, it will also keep your engineering team focused on other work.
Finally, a handful of integration platforms provide error webhooks so you can stream errors to your own observability platform like DataDog, Sentry, or New Relic. That way, your team can get ahead of any issues before you incur data loss in your customers' accounts.
Weighing the Benefits: In-House vs. Embedded iPaaS
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 simplify your decision, here's a table that summarizes each of the key components.
This was all quite high level, so if you’d like to experience the differences first hand with Paragon’s developer-oriented embedded iPaaS solution, you can schedule a demo or sign up for a free trial to test it out with your team!
