Four ways to build in-app integrations in 2024 - with pros & cons

Building integrations on top of 3rd-party APIs can be cumbersome, very time consuming and frustrating for engineers.

A proof of concept is often relatively quick & easy. Getting to a production-ready implementation is not: Retry logic, error handling, rate-limits and making the system scalable and fault tolerant quickly turns an afternoon project into a multi-week sprint.

Luckily there are a number of different options available today for engineering teams that want to speed up the development of integrations. Each of these solutions have different strengths and weaknesses: Which one is best for you depends on your use case, the APIs you are looking to build on top of and a number of other factors.

As we spoke to more than 100 engineering teams that build integrations we started to see patterns. We summarise them in this guide and hope it helps you find the best approach for your next in-app integration.

The factors to consider when building integrations

No two integrations are the same. How your integration works is often deeply tied to your product and the use case of your customers.

To find the best solution for your situation we think the following factors should be considered:

Level of interaction

Will you pull data in, push data out or offer a 2 way sync with the external API?

The depth of the integration

Will you just access 1-2 standard objects, push simple data in or are you looking to integrate with several features of the external system?
How will this change over time?

The complexity of the external system

E.g. calendars have a much simpler data model compared to CRMs, accounting or HR systems

The number of customers who will use the integration

Just 1-2 Enterprise accounts or a good chunk of your users?

The amount of data that flows through the integration

Are you pushing individual form submits with 5-6 fields each or are you looking to sync hundred/thousands of records a day?

The number of external systems you need to integrate with

Are there 2-3 dominant systems where you want to have a deep integration with many features? Or is a wide coverage of dozens of external systems more important for you?

‍

Pros & cons of each option

Let’s take a closer look at each of the options outlined above and their pros & cons.

Option 1: Build from scratch

The first option is to build your integration directly in your product using a library for HTTP requests, a background job runner and maybe an OAuth library. You build all logic and API interactions yourself from scratch.

Pros:

• Full access to the API & full flexibility
• Logic can be tightly coupled to the rest of your app
• Usually quite quick to build a basic proof of concept

Cons:

• Need to build your own infrastructure for pagination, token refreshes, rate-limits, schema mappings, scheduling, retry-logic etc.
• Scalability and reliability requires good architecture & experience
• Large maintenance burden as you need to maintain & improve all the infrastructure

Best fit for:

• Systems without any real APIs: E.g. accessing CSVs from SFTP servers, parsing E-Mails etc.
• Legacy, on-prem systems with very old technologies

Option 2: Using a low-code/no-code integration builder (embedded iPaas)

These solutions usually offer a (visual) workflow builder that offers pre-built integrations & actions. By combining these into steps and workflows you can build your own integrations with them. Most allow code snippets as steps to enable more advanced use cases.

Example Providers: Tray.io, Paragon, Zapier

Pros:

• The pre-built integrations & actions make it fast to get started
• Workflows can be adjusted for individual customers
• Non technical users can make edits and build without engineers

Cons:

• A limited number of integrations & actions available. These cannot be extended without work from the vendor
• These tools were originally built with low volume internal workflow automation in mind. Scalability is an issue for many beyond 1000+ objects to sync
• Integrations are not tied to your code base. The editor is often visual in a browser (even for code snippets). Versioning, releasing etc. are separate from your deployments

Best fit for:

• Bespoke, one-off integrations for (Enterprise) customers
• Simple integrations that only push simple objects to many external systems (e.g. form builders looking to push answers into CRMs, google sheets etc.)

Option 3: Using an API aggregator

API aggregators abstract different APIs of one category (e.g. APIs of HR systems) into a single API. Thanks to this you can integrate a single API and get integrations with many different systems at once.

Example providers: Merge.dev, Codat, Rutter, Plaid

Pros:

• Integrate one API and get dozens of integrated systems at once
• Learn the details of one API instead of dozens of different ones
• Most offer UI snippets for linking accounts

Cons:

• Limited API coverage: Only specific API types and providers covered
• Implement the lowest-common denominator across systems: Limited objects, fields & actions supported
• Sometimes knowledge the external system’s data model is still needed (e.g. different applicant tracking systems have different semantics of what a “hired candidate” is)
• Cannot be extended if a field or object you need is not supported. You need to build a new integration yourself

Best fit for:

• If the aggregation covers the fields & objects you need for your use case
• Your need to support dozens of systems of the same category (e.g. HR systems)
• Building integrations 1 by 1 would be particularly costly because the systems don’t offer real APIs (e.g. banks, on-prem HR systems etc.)

Option 4: Using pre-built infrastructure

Leverage pre-built, API agnostic infra for OAuth, continuous data syncs and transformations. With this option you get full access to the external API without the hassle of building from scratch. The pre-built components do all the heavy lifting and you just focus on composing them in your code.

Example providers: Nango, Pizzly

Pros:

• No coverage limitation: Works with any API & endpoint that returns JSON
• Full flexibility and access to the external API without the infrastructure hassle
• Easy & fast to build integrations that scale out of the box
• Logic of the integration can be tightly coupled to the rest of your app

Cons:

• Requires some understanding of the external API & data model
• Integrations need to be built 1 by 1 for every external system

Best fit for:

• Deep integrations with external systems (e.g. realtime or 2 way data sync)
• Teams that need access to the full external API but want to avoid building all the supporting infrastructure in-house

Conclusion

We hope this article helps you find the best solution for your next in-app integration. If you have any questions on how to build your next integration, feel free to reach out to us on our Slack community. We are happy to help!