Product integrations are now a must-have in almost all areas of SaaS. The 1000 fastest growing SaaS companies have an average of 98 product Integrations. SaaS companies who do not build product integrations will quickly be left behind by those that do.
In this article we’ll define native and third-party integrations, discuss their pros and cons, review how they can add value to a B2B SaaS business, and what organizations should consider when implementing either as part of their integration strategy.
An API (Application Programming Interface) acts as a means of communication between different software and apps and provides the tools needed for software to request data and other digital assets from each other.
%2520(1350%2520%25C3%2597%2520800%2520px)%2520(1500%2520%25C3%2597%2520800%2520px)%2520(1700%2520%25C3%2597%2520800%2520px)%2520(2).png)
This in turn allows businesses and software partners to use a company’s APIs to create, update, or perform actions (or workflows) with their data that meet customer needs. In the simplest terms, it provides a framework for developers who need to get one application talking to another.
Companies that offer an external API to customers or partners are exposing their services and digital assets to developers who can then build new applications, create new business opportunities or improve the existing product experience.
While APIs provide the tools that enable software programs to communicate with each other, integrations are built applications between software that both defines how the systems interact and runs the data.
Integrations can help companies provide their users the ability to create new workflows, trigger events, and pull and push data into various tools in their tech stacks. In SaaS, integrations are typically powered by APIs.
Integrations in general serve the purpose of creating a connected experience for users, allowing them to move data back and forth between systems. SaaS product integrations are designed for customers to be able to work seamlessly with all the products and services they use without having to manually move data or continuously toggle between systems.
Native integrations are integrations built directly between two or more software and are built by one or both of the system owners. These typically use each system’s APIs.
Native integrations use the data models of each connected platform or application and they can avail themselves of the full functionality supported by each partner system.
Native integrations enable SaaS companies to control the entire integration lifecycle, including development, design, implementation, support, and modification.
Because native integrations are built directly to each system’s API, and by at least one party who owns one of the APIs, they are able to achieve greater functionality, including leveraging all the potential actions of the API (like posting, getting, deleting, and updating data to each system). These integrations can be more customized and address a greater number of use cases that meet more of the end user’s objectives.
In addition, the user interface of the integration can be tailored within either system to provide for a better user installation and integration management experience.
While native integrations use one or both system’s APIs directly to power the integration, third-party integrations are created by third-party integration platforms or unified APIs who leverage their own pre-built integration connectors or APIs to construct the integration.
Embedded iPaaS (Integration Platform as a Service) solutions help SaaS companies to offer their customers third-party integrations. Embedded iPaaS’s standardize the way that data flows between different applications through their pre-built integrations. Their data models and workflows are often based on popular and recurring use cases seen across businesses.
Almost all embedded iPaaS's have visual workflow builders where a business user can set the flow of data between apps. They give a business user at a SaaS company the ability to specify the steps in a workflow, and when it should be executed, using a simplified UI or workflow builder.
In an ideal world, an embedded iPaaS enables anyone to be an integration developer without the need to learn how to code. However, because these are standardized and opinionated data models, when businesses need use cases outside the more popular workflows, they often have to assign a developer to learn to code around these visual builders.
Since third-party integration solutions have pre-built integration connectors, they allow companies to implement new integrations to their product more quickly than if they were to build them themselves. Once a connector is built from a company’s SaaS product to the iPaaS, the time to integrate one new application can go from many months to days.
The workflow builder UI offered by embedded iPaaS solutions means you can launch simple and moderately complex integrations faster without a developer.
A developer can also use a unified API to build one integration to many systems, which saves them the time of having to build multiple integrations.
Building integrations in-house from scratch is not only time consuming, but can also come with a high cost upfront in terms of developer hours. With a third-party integration solution, you’ll usually pay a monthly fee for the usage limit rather than a high upfront cost.
Third-party integration solutions can also be seen as a way to add MVP (minimum viable product) integration features quickly to your product and get feedback from customers without a significant upfront cost.
Building native integrations to a large number of systems takes a long time and a lot of developer hours. With an iPaaS or unified API, a SaaS company can offer integrations to hundreds or even thousands of systems fairly quickly due to their pre-built connectors.
iPaaS solutions and unified APIs work by standardizing data and, in the case of iPaaS, wrapping the data up in visual blocks so that a business user can manipulate them. This rigidity means the functionality offered by the underlying APIs is not fully captured.
As the number of partner applications and use cases for each application grows, iPaaS’s can only capture a fraction of those use cases. As a result, customers often cannot meet their business objectives when SaaS companies offer them third party integrations.
If a SaaS wants to offer more complex solutions, or wants to be able to iterate their integration offerings flexibly, or integrate to a new system not covered by the iPaaS, this eliminates one of the main allures of an iPaaS, which is that it requires less developer work.
Coding around third party solutions is harder than coding a native integration. It requires developing specialized knowledge of a proprietary system, and web services, database design, software design, and reporting.
Coding around visual builders or next to a unified API is not only likely to produce a technical frankenstein solution, developers rarely like doing it. It is one thing to become an iOS, Wordpress or Salesforce developer, as those are marketable skills, but specializing in an iPaaS is rarely why a developer joined a company and this risks employee dissatisfaction and the inability to find a developer willing and able to maintain the code.
When using a third-party solution to power integrations important to a product and its customer experience, company’s unavoidably become dependent on the provider. This includes technical dependency (when the system is down) but also dependency on their team to update all the connectors in a timely manner.
Keep in mind that APIs and SaaS are updated faster than ever, and an integration connector can quickly become obsolete in its functionality if the iPaaS doesn’t promptly update it.
An additional dependency arises because a SaaS company using an embedded iPaaS does not own or control any of the underlying code for the connectors. If a SaaS company churns off the platform, they would have to start building their integrations from scratch.
As mentioned earlier, companies generally pay a monthly fee (on an annual contract) for the usage of a third-party integration solution. Initially, if they are powering a small number of simple integrations to their product, this can prove to be a cost-effective way to implement integrations at a fast pace.
If integrations and product partnerships are an integral part of an organization's product roadmap and business objectives, being dependent on a provider to power integrations at scale can, however, result in extremely high and unpredictable monthly costs.
If a company is looking to implement integrations for more complicated use cases, it will also require significant internal engineering resources to learn the platform and code around it.
As discussed, iPaaS solutions only cover a portion of the functionality of the underlying APIs and, as a result, they often provide a less than stellar customer experience. Customers commonly are looking to move data in a way that the iPaaS doesn’t enable and become frustrated with the integration UX.
With some iPaaS’s, customers might also have to learn a visual builder interface, which depending on how technical they are can be time consuming and even impossible, resulting in them having to reach out to customer support.
When the iPaaS is not embedded in the app, like in the case of Zapier or Integromat, customers have to leave the SaaS app to install, manage, and pay for the integration – leaving the customer experience entirely out of the SaaS company’s control. Because of this, when issues arise this leaves the possibility of lackluster support that organizations have limited control over.
If integrations aren’t running properly, it can also be a challenge for the customer and the SaaS company to know where the problem is coming from. The support process can be drawn out as customers and the SaaS company try to troubleshoot the reason the integration isn’t working, which could be customer error, a partner app down, or issues with the iPaaS.
If the issue is coming from the iPaaS, the SaaS company often has to play intermediary between the customer and the iPaaS.
An embedded iPaaS provides no support for tech partners wishing to build into a SaaS company’s solution. It also does not facilitate a direct relationship between a SaaS company and the partner systems.
As a result, a SaaS company using an iPaaS to offer customers third party integrations will also have to enable technical infrastructure to support and work with partners. Having three-heads - the iPaaS, partner integrations, and native integrations built internally - to integration infrastructure can pose significant challenges to scaling and monitoring integration usage and success systematically.
The lack of direct relationship to partner systems also precludes successful co-development and API roadmap sharing that leads to higher quality integrations.
Native integrations give organizations the most control over their integrations including when data is exchanged, how it flows, and under what conditions. Native integrations provide the ability to set up workflows in the exact ways an organization’s customers need, and are only limited by the partner API.
If an organization is looking to scale its integration offerings and create a tech ecosystem around its product, the customization and agility to keep pace with product changes that native integrations provide is more suited to meet these goals as they offer a better partner and customer UX.
When an integration is native, because it is built as a direct connection between apps and their APIs, a SaaS company or its partner (or both) will have complete visibility into customer activity and data activity. This provides increased confidence that all the data is updated according to its sync schedule or in real time.
When integrations are third party, a SaaS company will often lack full visibility into the data activity, and often the partner will have zero visibility. With native integrations, a company owns and operates the integration so can have complete visibility into the data logs to understand how it is being used and, if they like, share it with their partner or enable their partner to view it.
This visibility can drive integration modifications based on how customers are using the integration and facilitate the quick communication of any errors and their source to customers. If errors are only coming from one native integration, for example, then it is likely related to that partner system being down.
Integrations improve customer retention and satisfaction when they represent use cases that B2B customers want, are easy to use, and are reliable. Integrations that have a great deal of functionality become critical to their users’ business processes, reduce inefficiency, and add significant capabilities to the underlying products.
Integrations are a key strategy for SaaS companies to combat churn but they are only able to do this if they provide a strong UX both at launch and over time. Because of their agility and direct access to partner APIs, native integrations excel in providing an exceptional user experience.
Native integrations and the technology partnerships that accompany them provide more opportunities for customer acquisition. Being a “premier” partner often requires a high level of activity visibility, functionality, and a technical set up that only comes from native integrations.
The positive reviews and greater adoption of native integrations leads to them being featured higher in partner app marketplaces, which converts more new customers.
Native integrations create a deeper understanding of partner products and fosters a direct relationship between the two SaaS companies. This ensures that better use cases are developed and more co-marketing and co-selling opportunities are engaged.
In addition, complex, highly rated integrations will result in closing deals that otherwise would have been lost to a competitor. In most SaaS categories, a robust integration to the keystone system (like Salesforce, AWS, or Zendesk, for example) is a base requirement to close many accounts. For other customers, it may be the deciding factor between a SaaS product and its competitor, leading to more new customers when the integration is robust.
When SaaS companies work directly with partner APIs, they acquire a greater understanding of the product and the synergies between their products. Co-building and co-innovating builds stronger integration partner relationships.
Satisfied customers further cement the relationship between partners as their joint customers express greater brand loyalty to both companies, and co-marketing efforts prove more fruitful.
Building native integrations in-house will be a more complicated process upfront than relying on pre-built solutions from a third-party provider. Customizing integrations to meet specific business needs will be time intensive and require engineering resources.
This can take up energy from an organization's technical employees, when they may have other priorities related to its core product. To ultimately be successful at implementing integrations this way and scaling them, companies have to spend money hiring specific engineers to build, maintain and update integrations, and grow this team as integration offerings grow.
The customization and greater functionality of native integration comes at the expense of efficiency. Native integrations take time to build. As an organization grows, and wants to build more integrations to support the needs of its customers, organizations may struggle to keep pace with growing demand while also prioritizing the development of their product.
In today's SaaS climate, business processes need continuous modifications. SaaS customers today expect interoperability between the software they use and they expect to work seamlessly with these products. The value of a product will go down if it isn't integrated with other software considered necessary in its sector.
This makes integrations a product differentiator and a catalyst for growth. Despite the many options available to organizations, integration struggles continue to slow down digital transformation initiatives for 87% of organizations and they are looking to SaaS companies to be part of the solution rather than exacerbating the problem.
When considering their integration strategy, SaaS companies can make the decision to prioritize core features, and outsource the integration service of a third-party provider to manage its integration lifecycle. However, we’ve already seen how this can cause lower customer satisfaction in addition to serious issues down the road for the expansion and customization of their integration offerings.
Alternatively, a company may want to reap the benefits of building native integrations in-house. However, given the resources and time required to take on this development, organizations risk falling behind in an environment where customers are expecting more product integrations out of the gate.
So, where is the middle ground? One approach used by the Head of Product Partnerships at Typeform includes building integrations in-house that are integral to their value proposition and users' business processes while utilizing third-party integration solutions for the long tail of apps that are only needed by a few customers.
But what if there was a solution that made it easier for organizations to build native integrations, support their partners in building native integrations, and reduce the need for in-house developer resources?
Pandium is an integration solution that provides organizations with the ability to build native integrations up to 6x faster with the use of it’s technical infrastructure. It eliminates much of the costs and processes that come with building, supporting, and maintaining native integrations, while also avoiding the rigidity and more limited customer UX of embedded iPaaS’s or unified APIs.
Building the infrastructure required to build, manage and support integrations is a heavy lift. Pandium's Platform and Integration Hub includes features that handle tedious aspects of building integrations like DevOps, Sync Triggers, and building the integration UI.
Pandium also enables developers to write the configurations for their integrations in the language of their choice, while Pandium handles the authentication, logging, hosting, and UI.
This approach also reduces dependency. SaaS companies using Pandium own and control the business logic code they (or their partner) create for the integrations powered through Pandium. This is approximately 60%-70% of the code needed for a native integration – a stark contrast to the iPaaS’s and unified APIs, who retain control of all the code and whose customers churn off without any usable code.
With many integration strategies and tools available, companies should understand their place in their customers’ tech stack and their strategic goals before deciding how to build their integrations. Evaluate what customers want from the product category and how critical integrations are to providing a good product experience.
If the use cases are relatively simple and unlikely to evolve over time, an iPaaS with third party integrations might be the best approach, especially if engineering resources are in short supply. Alternatively, if integration is absolutely core to the product, like with workflow automation or a customer data platform, consider owning everything in house and only offering native integrations.
Finally, if there is an intention to grow with partners, consider a solution like Pandium that enables native integrations at scale with much fewer developer resources.
.png)