Your organization will, inevitably, need to build integrations between applications, whether that’s connecting the applications your organization uses or integrating your product to the apps your clients use. 

Your initial preference for building any might be an approach that's referred to as point-to-point integration (also known as a native integration or P2P integration). But that doesn’t necessarily mean it’s the best option for your given integration use cases.

We’ll walk you through what this approach means, when it’s worth using (and avoiding), and your alternative options for implementing and maintaining integrations. That way, you can better decide what approach to use for each scenario.

What is a point-to-point integration?

It’s the use of custom code to connect one application with another. The code can be in any language and is typically geared towards accessing and communicating with a specific API endpoint provided by a 3rd-party application. 

Note: This definition differs from star integration (also known as spaghetti integration), which is simply a collection of internal integrations that are built using the point-to-point approach. 

Related: A guide to native integrations

Examples of point-to-point integrations

To bring our definition to life, let’s cover some common point-to-point integration examples. We’ll start by breaking down a few internal use cases and then review a couple customer-facing scenarios.

Ticket escalations

Your customer-facing team likely receives a number of client issues that require other internal stakeholders to resolve—in many cases, engineering.

To help your customer-facing employees flag issues to engineers successfully, you can build a point-to-point connection between the ticketing tool the former uses (e.g., Zendesk) with the tool the latter uses (e.g., GitHub) and build the following flow: Once a ticket is marked as "urgent" in the customer-facing team’s tool, it’s automatically routed to the engineering team’s platform.

The sync can also be bidirectional. In other words, as engineering updates the ticket, those changes get reflected in the associated ticket within the customer-facing team’s tool—allowing them to stay in the loop throughout the process of resolving it.

Employee pre-boarding

As candidates sign their offer letters, your team will need to move quickly in pre-boarding them—whether that’s purchasing equipment, provisioning applications, acquiring swag, etc.—so that their first day goes smoothly.

To help your team pre-board each new hire effectively, you can integrate your ATS and HRIS solutions and build a flow where any time a candidate is marked as hired in the former, their profile gets created in the latter. From there, HR and IT can learn about the incoming employee, and based on the information that was synced over to the HRIS, they can go on to complete the right set of pre-boarding tasks on the new hire’s behalf.

Automated user provisioning

To help any client manage users in your product with ease, you can build a point-to-point integrations with their HRIS solution and build a flow where any time an employee gets added, updated, or removed from the client’s HRIS, the corresponding change takes place in the client’s instance of your product.

Related: How to automate user provisioning

Intelligent employee intranet

Say you offer an employee intranet product for companies of all sizes, and as part of your product, you provide AI-powered search functionality. 

To help your search bar answer questions thoroughly and with complete accuracy for each client, you can build point-to-point integrations between your product and clients’ file storage solutions. From there, you can implement a flow where any time a client adds, updates, or removes certain files in their file storage solution, the associated actions take place in your product.

Your AI and machine learning models can read the data from these files and use their information to immediately answer commonly-asked questions, like “What’s the company’s PTO policy?”

Benefits of point-to-point integration

Here are some reasons to implement point-to-point integrations:

Addresses your requirements (if certain conditions are met)

If, say, you only have a few integrations you’d like to implement, they’re relatively shallow in scope, and you have engineering resources that can be allocated towards integration projects, then you might be able to build integrations successfully through the point-to-point approach.

Provides a somewhat simple path to management (if, again, certain conditions are met)

If you only plan to build a few point-to-point integrations and you have the right engineering resources available to maintain them, then it may be feasible to manage the integrations in-house over time. 

That said, most organizations need to implement more than a couple of integrations, especially in the case of product integrations; so, while this benefit may apply to your business today, it may not in the months or years ahead.

Allows you to prioritize specific integrations

Certain integrations are naturally more important to your business and/or your clients. By keeping integrations in-house, you can decide which to focus on and then build deeper connections— than what might be available from 3rd-party providers—to those apps. 

Enables developers to work on a project they're familiar with

Assuming you have engineers who have experience in building and maintaining certain point-to-point integrations, they may feel comfortable in taking on a similar integration project(s) in the future. 

Lets you avoid working with another 3rd-party

Aside from costs, 3rd-parties can be time consuming for your team—from having to go through renewal conversations to holding recurring check-ins. In addition, they can introduce risks to your business, whether that’s related to security (e.g. allowing data to fall into the wrong hands) or performance (e.g. 3rd-party experiences downtime). 

Finally, as we’ll cover shortly, many 3rd-party integration solutions are fairly complex. Your engineers will, as a result, have to dedicate ample time in familiarizing themselves with this type of platform before they even start using it. 

Drawbacks of point-to-point integration

Unfortunately, point-to-point integrations present several shortcomings.

Suboptimal use of engineering’s time

Your engineers are uniquely positioned to tackle business-critical initiatives—from bugs that hurt the end-user experience to feature enhancements that can differentiate your product. And while integrations are important, forcing your engineers to focus on them at the expense of other product-specific areas can ultimately be detrimental to your business.

Difficult to scale

Point-to-point integrations are difficult to scale because of the limited resources that can be allocated toward building and maintaining them. In addition, you likely have a seemingly never-ending list of integrations that need to get built—and engineering will find it difficult, if not impossible, to keep pace with this demand. 

Over-reliance on select individuals 

You likely have a handful of engineers (maybe just an individual) who can build and manage your P2P integrations. If and when they leave, they'll likely take information on the integrations they were involved in with them. 

This leaves your organization vulnerable when the integrations break or need to be improved; the remaining engineers will need to pick up the pieces and learn how the integrations work—let alone where they live.

Hard to manage

When integrations break, it’s likely imperative that their issues get resolved immediately. Any delays risks a poor customer experience and/or critical disruptions to your business processes, which carry downstream effects (e.g. leads stop getting routed). 

Using point-to-point integrations, it can be difficult to uncover issues on time, diagnose them with ease, and resolve them quickly—which can lead to the aforementioned consequences becoming reality.

Performance issues

With P2P integrations, it’s often difficult to move data quickly, especially in large volumes. This makes it poorly-suited to handle time-sensitive data syncs, such as syncing newly-signed clients between your CRM and ERP system so you can invoice them on time.

Related: The benefits of SaaS integration

Introduces security and compliance vulnerabilities

Depending on how your point-to-point integrations get built, they can present several vulnerabilities. 

For instance, if data isn’t encrypted in transit, the data can easily get intercepted and manipulated by attackers. And, depending on how a point-to-point connection handles the data, it may not comply with the data protection and privacy regulations you’re expected to follow; this not only leaves you prone to significant fees and  reputational damage—it also affects your relationship with existing clients.

Best practices for building point-to-point integrations

Let’s assume that you considered these pros and cons and ultimately decided to try implementing point-to-point integrations.

Here’s a few tips to help you build them successfully:

• Assign multiple engineers to a given integration project. Your engineers can leave at any point. To ensure they don’t take meaningful knowledge of the point-point-integrations they build and/or maintain with them, you can have multiple employees work on every integration

• Build out and maintain documentation on each integration. Even if your engineers stay at your company, they can easily forget crucial details on an integration. You can avoid relying on their memory by tasking them with documenting each point-to-point integration they build and/or maintain

• Perform a wide range of API integration tests. Building secure, performant, and reliable integrations requires conducting a range of different tests before pushing the integration to production, such as scale testing (to see how the integration performs when dealing with a significant volume of data), load testing (to see how effective the integration is in processing a high number of simultaneous requests), and so on

• Build robust monitoring and alerting processes. Every integration will, inevitably, break. To ensure that the impact of any issue isn’t significant, you can adopt a monitoring tool like Datadog and connect it to your business communications solution (e.g., Slack) and/or email so that every issue can get flagged to the appropriate stakeholders directly

Alternatives to point-to-point integration

If you decide to outsource your integrations you’ll likely consider a specific set of categories of tools. These tools will vary, depending on whether you plan to implement integrations for internal systems or between customers’ applications and your product.

Integration tools for internal applications

Here are the two most popular options for integrating your internal tools:

Integration platform as a service (iPaaS)

An iPaaS is a cloud-based integration solution that lets you implement integrations via APIs and deploy data flows that work across them. 

Their integrations are considered reliable and high-performing (since they use APIs). That said, the platform itself often requires technical expertise to use—which likely forces you to rely on engineers who can manage it. This, coupled with the fact that you’re only able to build one integration at a time with an iPaaS, makes it difficult to scale your integrations quickly.

Robotic process automation (RPA) software

RPA software uses scripts (also referred to as “bots”) to mimic human tasks at the human level—such as copying and pasting data between applications. 

This tool works great when the applications you’re looking to integrate don’t offer APIs, or don’t offer the API endpoints you need. However, the bots are often relatively brittle—a simple UI change can be all it takes to break a bot. In addition, the process of developing, deploying, and managing bots can also require technical expertise, which can make it difficult to scale your integrations and automations.

Integration tools for your product

Here are your main options for outsourcing product integrations:

Embedded iPaaS

An embedded iPaaS is simply an iPaaS that’s embedded into your product. 

You can deploy it in various ways. For instance, you can allow clients to use it within your application; you can use it internally and allow clients to access the integrations your team ends up building; or you can adopt a combination of both approaches. 

It offers similar benefits and drawbacks to an iPaaS. Namely, its integrations are reliable, but the process of building them quickly and at scale can be challenging.

Related: The advantages and drawbacks of an embedded iPaaS

Unified API

A unified API—or universal API—solution lets you offer multiple integrations with your product in a specific category (e.g. CRM) by simply building to a single, aggregated API.

‍Unified API solutions allow you to easily integrate at scale, which addresses the key drawbacks of embedded iPaaS solutions and point-to-point integrations. However, not all unified API solutions are created equal. 

Merge, the leading Unified API solution, stands out in several ways.

The platform offers hundreds of integrations across key software categories, from CRM to marketing automation to file storage to ticketing; it allows you to manage your clients’ integrations with ease through robust Integrations Management capabilities; and it lets your clients get all of the data they need via our comprehensive common models and through features that can access objects and fields outside of these models, like Field Mapping. 

Learn more about Merge by scheduling a demo with one of our integration experts.

Point-to-point integration FAQ

In case there’s still lingering confusion on point-to-point integrations, we’ve addressed several more commonly-asked questions below.

What is the difference between point-to-point integration and APIs?

Point-to-point integration is a specific approach to implementing integrations and may or may not involve APIs. An API, on the other hand, is essentially code that allow applications to communicate with one another.

How is point-to-point integration different from an enterprise service bus (ESB)?

The two offer fundamentally different approaches to integration; using an ESB architecture, organizations can connect applications via a bus-like infrastructure, otherwise known as a “bus”. In addition, organizations that adopt the ESB approach typically leverage a 3rd-party integration platform (e.g. Mulesoft).

What are the differences between point-to-point integration and an iPaaS?

An iPaaS is a 3rd-party solution while point-to-point integration is simply a way to build integrations in-house. That said, they overlap in that they approach integration builds on an application-to-application level (as opposed to unified APIs, which offer a one-to-many approach to integration).

What’s the relationship between point-to-point integration and middleware?

The two represent fundamentally different approaches to implementing integrations. Point-to-point integration doesn’t involve the use of middleware—which is a 3rd-party tool that can help you implement and maintain integrations.

How does point-to-point integration compare to hub-and-spoke integration?

Point-to-point integration doesn’t involve a central hub that facilitates communication between applications (which is essentially what hub-and-spoke integration entails); instead, point-to-point integration allows applications to communicate directly with one another.