Note: This is the latest in our Partnerships 101 series. You can read the other entries here.

Tech partnerships are a part of our daily lives. No, really — every time you stream your favorite Spotify playlist through your Amazon Alexa or watch your Lyft driver navigate to your destination using Waze, you are benefiting from a tech or “integration” partnership.

But now you’re a partnership professional. It’s time to move from enjoying these partnerships to being responsible for making them. That means you’ll need to understand some basic details.

Key among them: the direction of the data plays a large part in how feasible and useful an integration can be. In fact, if you are considering forming a tech partnership, making sure the “traffic rules” of your future integration are crystal clear is an important first step.

In this post we’ll cover:

Let’s get started!

A quick refresher: Technology partnerships are formed when two or more companies integrate their products with one another (giving them their second and not-all-too-creative name: “integration partnerships”). This can include sending data back and forth, creating new workflows, triggering events, and enriching data. Tech (or integration) partners make money by co-marketing and selling their integrations, and through higher customer retention.

However, as we know all too well, there is more to a partnership than just…deciding to partner up. So what exactly makes the “integration” part of integration partnerships possible? This is where APIs come in.

APIs, or application programming interfaces, are the foundation for all of the integrations that we use on a daily basis. These blocks of code act as messengers, connecting tech systems and getting them to communicate with one another quickly and seamlessly. There are more than 20,000 public APIs underpinning tech integrations today. And while you might have never known they existed, we guarantee that APIs have made your life easier.

Think about how simple it is to share a song from Spotify to your Instagram story. Two different services, one action, and it takes only seconds. This is an API-based integration at work. We have seen a shift from the old days of monolithic software systems to an API economy where systems build off of one another, expand partnership ecosystems and make things easier for everyone involved.

Imagine you are asked to plan out a highway. What is the first thing you need to figure out? Are cars heading north? Are cars heading south? Is it a divided highway with cars going both ways? Should I save this game of SimCity and get back to work? These questions must be answered before anyone can safely drive on the highway, and it’s no different when it comes to sharing data.

In fact, for tech partners, integrations are defined by the direction data moves and it’s crucial that all involved parties are on the same page. It sets the terms for everything that comes after, so before you plan on making an integration, get clear on what data is going where.

There are three categories of integration data flow: inbound (incoming), outbound (outgoing), and bi-directional (data flows both ways). Remember, defining the type of integration is dependent on the partner’s point of view. Data that’s inbound for one service may be outbound for the other.

An integration is “inbound” for a service when the flow of data is exclusively coming in from a tech partner. When a newsletter sent via MailChimp is automatically tweeted out, that is an integration for Twitter (and an “outbound” for MailChimp, but we’ll get to that). When the answers from a Typeform automatically sync with a Google Sheet, that is an inbound integration for Google. Many of the most popular services rely heavily on inbound integrations to support their data with the data of their partners (we call this second party data). Slack, Salesforce, and HubSpot are examples of services with a high number of inbound integrations.

An integration is “outbound” for a service when (you guessed it) they are exclusively pushing data out to their tech partner.When Segment pushes captured user data to Kissmetrics to be used for reporting, segmentation, and targeting, this is an outbound integration for Segment. When you buy something using Apple Pay and they push your payment data to Square, this is an outbound integration for Apple. Again, it’s all about perspective: Flip these examples around and you’ve got two inbound integrations for both Kissmetrics and Square.

An integration is “bi-directional” when data flows to and from both tech partners. Take the integration between Monday.com and Adobe Creative Cloud. Projects created in the Creative Cloud are directly linked within a task on Monday.com where they can be reviewed. The creator also has access to these edits through a pop-up Monday.com page that lives within the Creative Cloud application. Updates on either end automatically sync between both services, driving more efficient, real-time feedback. Google’s integration with Calendly is also bi-directional. Events created in Calendly are automatically published to the corresponding Google Calendar. If that event is deleted or edited on either end, that change appears in both locations. In other words, a bi-directional means the systems are engaged in a conversation rather than a monologue.

—

Unfortunately, being an expert of the different kinds of integrations is not the same as actually building a tech partnership (although if it was, you would be all set). However, it is the first step in getting there. The next time you are contemplating forming a tech partnership, take a second to get everyone on the same page.

Ask everyone if they want the integration to be: