How we built a Salesforce API integration in 3 hours

Integrations have a reputation of being difficult, costly and time consuming. Often APIs are not as straightforward as they look at first glance and the Salesforce API has a particularly bad reputation. The result is that integrations end up taking more time and engineering resources than expected.

In this article we will give you an overview of four different approaches for building a Salesforce integration, with pros and cons for each.

Then we will show you how we built a Salesforce integration that continuously syncs Contacts and Accounts from the Salesforce API to our SaaS product in 3 hours with Nango.

But first, let’s look at the most frequents goals we hear from teams that are building integrations:

• Ship a first version fast
  They want to ship a first integration fast to deliver value as quickly as possible and learn what customers value.
• Ability to iterate fast & ship better versions
  As they learn, they want to quickly change the integration (e.g. fetch more/different data) to ship better versions of it and continue learning with customers.
• Minimize engineering time & maintenance
  They want to focus their engineering efforts on the core product and minimize the engineering time and maintenance required to ship and maintain the Salesforce API integration.
• Keep control: Build the integration as we need it
  They want their integration to be as helpful for customers as possible. This means they don’t want to be constrained by their platform or approach in what they can build.

With these in mind we can discuss the different options we have to build our Salesforce integration.

Overview of 4 different ways to build a Salesforce integration

Each of the following approaches has different tradeoffs. With our goals in mind we can look at the pros and cons of each solution.

Option 1: Build the integration in-house with libraries & frameworks

As engineers our first instinct is often to build things ourselves: We know code, REST APIs and maybe even worked with OAuth. Why not just get some libraries together and build the integration directly in our product?

Pros:

• Flexible & full control: We can build our integration exactly as we want
• Known environment: We can re-use our data models, frameworks, tools and release process from the rest of our product.

Cons:

• Need to understand Salesforce OAuth and REST API in detail: We need to research the API, understand how Salesforce OAuth works and build everything from scratch
• We need to discover and work around Salesforce specific API quirks and OAuth issues.
• We need to build infrastructure and find libraries for handling OAuth, access token refresh, background jobs, change detection, rate-limit handling, monitoring etc.

Summary:
‍Flexible, but it can easily take days or weeks to ship a first version of the integration. We also need to develop infrastructure for the integration, which probably takes several iterations to get right and requires significant maintenance in the future.

Option 2: Use an embedded iPaaS

If you are familiar with Zapier you know embedded iPaaS systems: They give you a drag & drop editor to build “workflows”, where you can use pre-built steps and components to do things like read a Contact, create a Contact, listen to a webhook, send API request etc.

Pros:

• Pre-built auth: Most of these systems take care of the API key or OAuth fetching for you
• Pre-built workflow steps: They typically have pre-built steps for creating a contact, fetching a list of all accounts, performing a search etc. These abstract (some of) the API endpoints away for you.

Cons:

• The integration workflow is built with a drag and drop UI and is not connected to the rest of your application code. If you want to write custom requests you need to write code in the UI & it lives there.
• Often the pre-built workflow steps only cover a small part of the API: If you need access to other data you have to write custom API requests in the drag & drop UI. Extending pre-built steps is often impossible.
• Workflows are often optimized for small read or write based workloads. Performance (and pricing) can be an issue with large data syncs that need to sync 10’000+ contacts, accounts or other objects.

Summary:
‍Embedded iPaaS tools take away some of the burden of working with the API by abstracting away authentication and some common API actions. Their no-code/low-code approach can be limiting though, as the pre-built parts only cover a section of the API. If you need more, you need to write custom code in their UI.

Option 3: Using a unified API

Unified APIs take a number of different APIs from similar systems (e.g. CRMs) and bundle it together into a single API and data model. Instead of building integrations with each, you build one integration with the unified API and can access data from any of the source systems through it.

Pros:

• Abstracts away (some) of the API specific differences between CRMs by consolidating them into a single data model. You integrate once and get support for many different systems.
• Pre-built infrastructure for authentication, data syncing, monitoring etc.
• Developer first experience: Access data through REST APIs, receive webhooks on changes etc.

Cons:

• The unified data model can only implement the lowest common denominator across all systems. This works fine for basic data, but means you cannot easily use a feature or access data that is specific to one system or API (e.g. specific fields, activities, custom objects etc.)
• Despite the unified model, if-else statements can still be needed: Different systems give the same data different meanings (e.g. status of a lead, last changed dates, objects are used differently in the different systems etc.)
• If you need data that is not supported by the unified model you have to build workarounds and set up your own data syncing infrastructure to fetch it.

Summary:
‍If the unified data model covers everything you need, unified APIs can be a good solution as they abstract away a lot from the underlying APIs. If you need data not covered by the unified data model you might find yourself building from scratch, as you now need to make manual API requests, study each source API, setup your own data syncs etc..

Option 4: Open-source platform for product integrations

Product integration platforms combine the best of building in-house and unified APIs: They give you pre-built templates for common use-case such as syncing contacts or accounts from a CRM.

But because the platform itself is open you have full control over these integrations and can extend and customize them as needed, whilst taking full advantage of the platform and the pre-built infrastructure.

Pros:

• Pre-built auth, data syncs and data models like unified APIs.
• Flexibility to customize and extend the pre-built data integrations and data models, whilst keeping the full support of the platform and pre-built infrastructure
• Single interface and platform that supports both unified data models and individual, deeper integrations with some systems

Cons:

• If you customize data syncs or write your own you still need to understand some of the endpoints of the external API (and its data model)
• If you need data from the external API for which no template exists you need to write your own data syncs (on the platform).
• Like unified APIs, data from different systems may have different meaning

Summary:
‍Product integration platforms are a good fit if you want to benefit from the fast time to market of unified APIs, without being constrained by the unified data model. Because you get access to the underlying platform and infrastructure, customization is comparably fast and easy. But it still requires you to understand some details of the API & endpoints you are looking to use.

For our use-case and goals described above we decided to build the Salesforce integration on top of Nango, an open-source platform for product integrations.

How we built a Salesforce integration with Nango in 3 hours

For the first version of our Salesforce integration we were looking to sync both contacts and accounts from Salesforce to our app.

From there we could extend data syncs to other objects, include more fields, write some data back as needed etc.

Building this Salesforce integration with Nango has three steps:

1. Setup Salesforce OAuth with Nango (~30 minutes, including registering the app with Salesforce)
2. Copy the pre-built Nango templates for Salesforce contacts and accounts sync into our Nango account (~10 minutes)
3. Setup an endpoint in our app to receive the Nango webhook whenever new data is available. We then use the Nango SDK (or REST API) to fetch the new data and process it in our app (~2.5 hours)

With the Nango dashboard we can see the status of every sync and have full visibility on the status of our integrations.

Conclusion

When building an API integration with Salesforce there is a tradeoff between building something very fast with pre-built solutions and the flexibility to customize and extend integrations in the future.

Different solutions have different tradeoffs, but we believe that an open-source integrations platform can combine the best of both worlds: Build integrations fast, by leveraging pre-built templates and a lot of pre-built infrastructure, and keeping full control over the integration, to build exactly what you need.

Thanks for following along! If you are interested:

• Learn more about Nango here
• Check out all the 250+ supported APIs
• Join the Slack community with 2,000+ engineers and product managers building integrations

Useful resources

How to build integrations you and your customers love

Should you build or buy product integrations?

The hidden costs of building product integrations in-house

How to find the best integrations partner