Common B2B SaaS Integration Patterns and When to Use Them

According to a recent survey, the number of SaaS companies has grown to more than 25,000 worldwide. In general, businesses that subscribe to SaaS products work with multiple SaaS vendors and expect that the apps will integrate with each other. To address this, some SaaS companies build bespoke integrations into their apps, while others go with an embedded integration platform to address their customers' integration needs.

Regardless of the approach you are taking for integrations with your app, you'll find that most integrations should fit into a few common patterns. Knowing these patterns will help whether you find yourself in the midst of an integration project, just getting started with building out your API, or in the early days of planning a new SaaS app.

In this post, we'll briefly examine these patterns and learn the benefits of each.

Common Integration Patterns

• Event-driven – An event occurs in an app, which causes data to be sent to another app. The event may be in your app or the third-party app with which you are integrating. This is the most common type of integration between SaaS apps.
• Scheduled – An integration that runs on a regular schedule (every minute, every hour, daily, and so on). These integrations include exports (such as recurring reports) and imports (such as polling an API to request data for import to your app). Scheduled integrations are often used between a SaaS app and non-SaaS application.
• Synchronous – One app makes a request, then waits for the integration to complete and respond with an answer. Because of timing, this can be the most difficult type of integration to implement successfully. It is not used as often as the event-driven and scheduled integration patterns.
• Hybrid – This one is not so much a pattern as a combination of other patterns.

Event-driven Integrations

This is probably the most common type of integration for SaaS apps. When an event occurs in a source system (for example, a customer record is updated in CRM or an invoice is paid in POS), data about the event is sent to a destination system.

This data is generally sent via a webhook. A webhook is an event-triggered request to an app (the third-party app for an import integration or your app for an export integration). The payload is the data sent by the webhook to the destination system.

If the source app is not using an API with webhooks, it may be using a different type of pub/sub system such as Amazon SNS, Apache Kafka, or even email. In those cases, the destination app subscribes to what those systems provide.

For a great example of an event-driven API, consider GitHub, which has a variety of events that can trigger a webhook. GitHub also provides the shape of the payload sent via each webhook. When you integrate with GitHub, you'll create endpoints to receive those payloads.

If you are interested in ensuring that data is transmitted speedily, that your event-driven API is reusable for multiple integrations, and that third-party developers have an easy path to building integrations with your app, you’ll definitely want to set up your app and API to support webhooks.

In the following sections, we’ll look at various event-driven integrations.

Event-driven Import Integrations

An event-driven import integration is an import of data from the third-party app to your app based on one or more events in the third-party app. The integration may have a single payload or multiple payloads. Within the integration, a payload may move through a single sequence of activities (a flow), or it might go through multiple flows or branching logic to be filtered or otherwise transformed before your app consumes the data.

The key to an event-driven integration for import is that the third-party app publishes the data (via webhooks or another pub/sub system), and your app subscribes to that data.

Event-driven Export Integrations

An event-driven export integration is an export of data from your app to a third-party app based on one or more events in your app. As with an import integration, you may be handling a single payload or multiple payloads. And the logic may be simple (a single flow) or complex (multiple flows).

The key to an event-driven integration for export is that your app publishes the data (via webhooks or another pub/sub system), and the third-party app subscribes to that data.

Event-driven Two-way Integrations

An event-driven two-way integration melds the import and export functions into a single integration. The import portion will have its logic, and the export portion will have separate logic, but everything is contained within a single integration. Two-way integrations could be split into separate import and export integrations, but they are usually combined to provide straightforward deployment and support processes.

In an event-driven two-way integration, both your app and the third-party app are publishers and subscribers.

Scheduled Integrations

When the system you need to transfer data from does not have webhooks or another pub/sub system to which you can subscribe, you need to use a scheduled integration. A scheduled integration can be either import or export. Instead of being triggered when the integration receives a notification, a scheduled integration is triggered at a specific time or time interval. Your integration can go out and query for data, and then send that data off to another app, a data storage system, or a messaging system like Slack, email or SMS.

The data may be only a minute or two old for a scheduled integration that recurs frequently, but it will not be as fresh as data from an event-driven integration.

In the following sections, we’ll look at various scheduled integrations.

Scheduled Data Import Integration

You'll need a scheduled integration to import data from a third-party API that does not have webhooks or another pub/sub system. In this case, the integration must wrap the third-party API endpoints containing the data the integration will query. The API then processes the query and returns the requested payload.

Scheduled File Import Integration

Some third-party apps may be configured with file export capabilities instead of an API. This scenario is more likely with non-SaaS (legacy) systems. In this case, the app may write out data as PDF, XML, CSV, or another file type to an external data source such as Dropbox or SFTP. To import this data, you'll build an integration that checks the location(s) according to a regular schedule to see if there are new files to process.

When there is new data within the location (for example, new XML files in a Dropbox folder), your integration will loop over each file, process the files, and then move or delete the processed files. As with other scheduled integrations, this still is not near-real-time but can be current within a few minutes of the file(s) being placed in the external data source.

Scheduled File Export Integration

You'll use this type of integration when you need to generate and send a regular report to your customers. You set up an integration where you are either querying your API (for your app) or a third-party API for specific data.

Once the data has been returned, your integration generates a file with the data in the necessary format (PDF, XML, CSV, and so on). Finally, this file is packaged up and sent off to its destination (which could range from a filesystem to email or SMS).

Synchronous Integrations

A synchronous integration may be what you need if you have data from a third-party app that you must have right now. An integration of this type calls an integration URL and then waits for a response.

The synchronous integration should function well if it works quickly and has little to no lag between the call and the response. However, if the integration takes a while to run (for example, if there is a lot of data to process, or if the third-party app is slow in fulfilling requests), the integration becomes susceptible to network disconnects and timeouts.

Synchronous integrations are useful when the order of operations matters. For example, if your sales system receives an order and you send data to a payment processor integration, you probably want to wait for a response that the payment was posted successfully before you send data to your order fulfillment integration. As you build an integration for these scenarios, you’ll need to decide if waiting for a response is right for you or if you should have the payment processing system "call you back" when the payment is successfully run asynchronously.

Hybrid Integrations

Hybrid integrations are some combination of other integration types. For example, suppose that your app supports webhooks, but the third-party app you are working with only has an API with no webhooks. As a result, you might build a hybrid integration where you have an event-driven export from your app but are running a scheduled data import from the third-party app. Instead of setting this up as two separate integrations, you would be able to combine them in the same integration with distinct flows and logic.

Conclusion

While integrations may be defined simply as software that transmits data from one system to another, details can vary considerably from one integration to the next. When planning and building integrations between your app and your customer's third-party apps, it's essential to consider integration patterns, ensuring that you use the best pattern for each integration scenario.