DEVOPSdigest

On average, companies use 130 SaaS applications (BetterCloud 2023 State of SaaSOps Report) to manage operations, leading to fractured workflows. Eight in 10 (SalesForce 2023 Connectivity Benchmark Report ) say integration challenges are slowing their digital transformation. B2B SaaS companies add enormous customer value to their products with built-in integrations to their customers' other tools. These connections reduce friction and streamline tasks.

Could your SaaS company use your existing developers to build integrations entirely in-house? Absolutely. But should you? Possibly not.

On the surface, connecting systems might appear to revolve around writing code. But so much more goes into delivering integrations, and these additional facets are what truly drain developers' time. Let's explore these "other" details required to build a B2B SaaS integration environment.

Infrastructure

In addition to building the actual integrations, your team must figure out infrastructure and deployment strategies. First, you'll need to provision compute resources that can run your integration code. This approach differs based on the system you're using.

Once you outline infrastructure, you must figure out how to deploy and update code, which also requires considering numerous options and scenarios. Swapping out containers or Lambda definitions works for container or serverless deployments. Servers, VMs and EC2s will require more advanced blue/green deployments. Teams must also answer questions like:

■ What happens if your integration is executing when a container is replaced?

■ Can you easily roll back to a previous version when issues happen?

■ Can you quickly deploy different versions to different customers?

Scaling infrastructure is yet another challenge to consider. Data moves between applications in bursts, and your system must be able to handle the ebb and flow of these transfers. At the same time, misconfigured third-party apps can overload your servers, which requires creating additional configurations to protect you from scaling resources unnecessarily.

Integration UI for customers

For many B2B SaaS products, the ultimate goal is for customers to activate integrations themselves. Sure, building a basic listview screen is straightforward for a front-end developer. But what happens when your team adds more integrations? This brings about questions like:

■ Will the front-end developers need to be involved with every change?

■ Who maintains the list of integrations?

■ Can you display different lists of integrations based on pricing tiers?

Next comes the integration configuration experience, which is more complex than a customer providing you with their third-party app credentials. You must:

■ Decide between creating custom code for each configuration or building a generalized solution.

■ Track all these configurations for each customer, likely requiring you to build new APIs to ensure the integration code has access to the proper configuration.

Depending on your process, your backend team may need to be involved with each integration.

OAuth 2.0

Many applications use the OAuth 2.0 authorization mechanism. It's simple and easy for users but requires significant backend work, including:

■ Setting up a predetermined callback URL to handle the return from the third-party app's consent screen.

■ Implementing a mechanism to track user and integration information using a state property within the callback URL.

■ Establishing infrastructure for generating OAuth authorize URLs and receiving authorization codes from users.

■ Ensuring that the OAuth callback URL can exchange authorization codes for access tokens with the third-party apps.

■ Developing an OAuth service that periodically refreshes tokens for all integrations and alerts you if a token refresh fails.

Webhook infrastructure and event scheduler

Event-driven integrations are ideal for moving data between apps. You can use a webhook payload to notify your app that a third-party app event has happened. To support this function, you need to build a service that:

■ Determines which customer and integration a webhook payload is for.

■ Dispatches the request to the appropriate compute resource.

■ Queues up requests if resources are not appropriately scaled.

You also need to define retry logic for failed requests. If an application does not support webhooks, you must build a service that invokes integrations on a schedule.

Data logging

All of the previously-mentioned services will create logs, which need to live somewhere. The infrastructure you build must capture the logs from your runners and supporting services, which usually involves installing agents from your log provider on your infrastructure and keeping those agents up to date.

Monitoring

It's an unfortunate reality that all software will fail at some point. When something goes wrong with an integration, you want to detect the problem before your customers do. Your log provider might include monitoring features, but they'll require fine-tuning to detect failure accurately. Depending on your needs, you may require an additional monitoring service to send alerts to your team when an integration isn't behaving as expected.

Testing

Your integrations will require a way to quickly deploy new versions to a production-like testing environment. Integrations are iterative, so you need effective strategies to deploy and test new code efficiently without tying changes to core product updates. Adding to the challenge, you can't always test against a vendor's test endpoint, requiring you to create a mock endpoint.

Security

Managing security between applications is difficult. Properly protecting data requires building infrastructure to encrypt third-party credentials in transit and at rest — and designing data protocols so integrations can only access relevant credentials and configurations. You'll need to consider:

■ How you monitor the infrastructure.

■ What normal vs. abnormal function looks like.

■ How to detect and respond to incidents.

Certain customers might require your integrations to comply with strict industry-specific regulations, adding additional complexity.

The cost of in-house integration building

B2B SaaS development teams are entirely capable of accomplishing all of these integration tasks, but at what cost? Skilled engineers spend months working on these behind-the-scenes integration needs rather than focusing their energy on enhancing the core product.

There's no doubt about it — integrations are business-critical and harder than they look. Rather than draining engineers' time and creativity, consider how your company can reduce integration burdens with technology — like embedded integration platforms — that are capable of doing some of the heavy lifting. Simplifying integrations benefits your engineers, your product and your customers.