Synopsis: Learn how integrations became the glue that binds the SaaS world and their importance to any SaaS startup.
If you look at the offering of almost any SaaS company today, you will inevitably find a list of third-party services with which they integrate. This holds true regardless of industry, whether it is a financial services company like Stripe, communication household names like Zoom and Slack, or a developer focused player like GitHub. The trend is not limited to large established companies – smaller startups also tout their integrations as selling points. Zluri (2020), Phyllo (2021), and eqtble (2021) all prominently feature integrations from their homepage.
Integrations are also called “apps”, “zaps”, “connections”, “sources”, “add-ons”, and “plug-ins''. Regardless of their name, they all do more or less the same thing which is integrating a SaaS company’s offering with another service.
What is an integration?
In its simplest form, an integration connects two different services and allows them to interact and share data. Some concrete examples include the Zoom add-on for Google Workspace that allows you to add a Zoom meeting to a calendar event or, my personal favorite, the Giphy integration for Slack that lets you respond to messages with topical GIFs.
Why are integrations so vital to SaaS?
Take a second and think about all the services you regularly interact with on a daily basis. I imagine the list goes something like this: Email (probably gmail), a messaging tool (Slack), a video conferencing tool (Zoom, Teams or Google meet), a work-tracking tool and some sort of CRM. If you are in the software world, I would also add in a hosted VCS (GitHub, GitLab, BitBucket) along with CI/CD tools. These are a minimum set of services; there would be dozens of other less commonly used ones. To put a concrete number to this, a survey by Productiv found that a typical department within a company uses 40-60 tools. Departments like Security, Engineering and IT use even more.
These various packages cost money, but there is also a cost to productivity. Contrary to popular belief, our brains do not multitask but rather context switch. This requires disengaging your attention from one service and bringing it to another. Then the process takes place again going back to the first service.
Data duplication often leads to a further productivity hit as you copy/paste from one service to another. Wouldn’t it be better if machines could coordinate between the different services for you? This is where integrations come in.
Integrations enhance the experience of working with multiple services, reducing context switching, automating manual steps, aggregating data, and allowing you to utilize specialized services to enhance the core services of your everyday life. And this benefits more than just the services end-users. SaaS companies can leverage the power of integrations to quickly add missing functionality via a complimentary service. They can also embed the service itself into an already existing ecosystem.
How are integrations built?
Software products, even before SaaS, used extensions and plug-ins to extend core software functionality. Some pre-SaaS examples include extending Emacs via Lisp or creating a plugin in Java for the Eclipse IDE. But knowing how to extend Emacs via Lisp did not help at all if you wanted to extend Eclipse via a plugin.
In contrast to the extension capabilities of old, the (REST) API is the SaaS de-facto extensibility standard. And APIs are no longer just meant for extensibility either – there are entire services that are API-first. Their APIs are the service. This makes knowledge of how to work with APIs wide-spread and applicable to nearly all SaaS applications.
So far we have talked about extensibility of SaaS services and not integrations but an integration is nothing more than a specialized extension for two services. An integration is typically built by extending (using the API of) service A and extending (using the API of) service B to allow them to interact and share data. If we are continuing our glue analogy, the APIs of service A and B are where we would put the glue on to bind them.
Rest APIs are not the only means of integrating SaaS products, entire companies dedicate themselves to integrating SaaS products in various ways. Some of these, which we will talk about later, even allow you to “integrate” various SaaS products yourself in easy-to-use flow-builder UIs, but it should be noted that for those services to offer those DIY integrations, they themselves have almost certainly extended the API for you and are merely providing a pretty (and useful) layer on top of it.
There is a little more to the story of building integrations such as the proliferation of SDKs, the various authorization mechanisms, push vs pull, and event or batching, but APIs are at the core of it.
Marketplaces and distributing integrations
Since an integration connects two services, it is often built by one of the services or in partnership with both. One common strategy to leverage others to build integrations for you is to offer a marketplace. A marketplace formalizes the process of creating and distributing integrations. This lowers the barrier for other services to integrate with your service. Not every SaaS company can build a marketplace but virtually any SaaS company should be capable of building an integration for an existing marketplace. Take the example of Datadog which has a very well defined process of how others can build integrations for the Datadog Marketplace. As a result, they have over 500 integrations – about half built by others for them.
The business of integrations
Integrating various services is so vital to the SaaS ecosystem that entire companies are dedicated to integrating these services in various ways, they include:
iPaaS or integration Platform as a Service is a platform that allows for the integration of various services, whether cloud or on-premises. These tend to be geared towards larger or more complex use cases and are often very powerful and configurable but require some expertise to set up and run. Examples include:
iSaaS or integration Software as a Service is quite similar to iPaaS but may not be as configurable. The tradeoff is that these services are typically easier to use and set up, making them preferable for smaller to medium sized companies. Examples include:
Workflow managers are more purpose oriented, most iSaaS or iPaaS solutions may be able to accomplish what workflow managers do but those solutions would require more configuration and potential complexity. Examples include:
Data Integration Platforms
Data integration platforms are another related category but with an emphasis on collecting and aggregating data from the various services instead of coordinating their interactions. This can include normalizing the data to make it easier to query or transforming it to deliver it to a different specific destination.
All the categories above allow users to build their own workflows or have an opinion on how two or more different services should interact with each other. The integrations in this section are built (or commissioned) specifically by a service to interact with other services. This comes with a built-in opinion of how the native and external services should interact. For the end-user, it eliminates the need to have a third service or platform just to manage integrations. The negative for the service providers is that they have to plan, build and maintain a potentially large set of integrations (one per external service). For this reason, built-in integrations tend to be limited.
Integration categories are blurry
It should be noted that the categories above are somewhat blurry. A SaaS company may fall into more than one category. For example, a “Built-in” integration provided by a service may actually be built by leveraging an iSaaS or data integration platform. In fact, a common solution for new startups to leverage the power of integrations is to utilize existing integrations platforms. It’s much easier to plug into an existing ecosystem like Fivetran and Zapier than to build hundreds of custom integrations.
Integrating with DevRev
DevRev understands the value of a connected world. Not only are we connecting Dev to Rev, but we are also harnessing the power of integrations with the tooling you are already using to make it possible. It doesn't matter if you're talking with customers over Slack, email or a widget on your App. DevRev connects your customer (Rev) conversations, requests and usage with your product and builders (Dev). This allows you to avoid manual copying, context switching, and provides a richer set of data to make informed product-building decisions. Keep an eye out for our upcoming marketplace and flows and see how they can help you connect your Devs to your Revs.