According to a recent report, the number of SaaS companies has grown to more than 30,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 need for B2B integration, some SaaS companies build bespoke integrations into their apps, while others go with an embedded integration platform to address their customers' integration needs.

The number of B2B integrations has exploded with the increase in SaaS applications. Not all B2B integrations connect SaaS systems, but as traditional client-server applications are phased out in favor of SaaS applications, newer B2B integrations are likely to be built between SaaS apps.

Regardless of the approach you are taking for building integrations with your B2B product, 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 B2B SaaS 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, etc.) 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

Event-driven integrations are 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, etc.) 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 (much data to process, the third-party app is slow in fulfilling requests, etc.), 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.

Frequently asked questions for B2B integrations

Question: What is B2B integration?

Answer: B2B integration (or business-to-business integration) is connecting applications between two or more companies for data exchange. Most B2B integration today connects SaaS applications and automates key customer processes, allowing users to focus on tasks more suited to their skills.

Question: How does a B2B integration platform work?

Answer: A B2B integration platform (also known as an embedded iPaaS), is a tool that helps software companies build and manage native integrations connecting their products to the other apps their customers use. It does this by providing out-of-the-box functionality to enable the building, deploying, and support of B2B integrations.

Question: How does Prismatic help with B2B integrations?

Answer: Besides providing the functionality to build, deploy, and support B2B integrations, Prismatic enables SaaS companies to productize their integrations, providing configuration flexibility that allows one integration to be deployed to many customers, each with its custom configuration. End users may activate, reconfigure and troubleshoot their own integrations. They can also build and deploy their own integrations with the embedded designer.

Use the best pattern for each integration scenario

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.

For more on how B2B integration software can help you with your integrations, check out our post on embedded iPaaS.