Four ways to build in-app integrations in 2023 - with pros & cons
The best way to integrate your app with a 3rd-party API depends on a few factors. We show the pros & cons of four different approaches.
January 12, 2023
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.
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
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
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
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.
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
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.
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
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
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!
Share this article:
Co-Founder & CEO
Originally an engineer himself Robin has worked on product integrations for 6+ years.
Today he is a co-founder at Nango.