Thought Leadership

5 Reasons Why Native Integrations Are Hard

Avery Yip
CEO & Co-Founder
Published On
June 1, 2023

At first, building integrations seemed like a breeze - after all, many of the tools I use already connect seamlessly. If everyone is doing it, how hard could it be? However, my personal experience has taught me that creating customer-facing integrations is far from easy.

During my time at Productiv, we had over 20 engineers dedicated to building and maintaining integrations. At Vessel, we’ve built integrations with various apps such as Salesforce, HubSpot, Slack, Mailchimp, Zoho, Outreach, and more. What I once believed to be a simple task has turned into a challenging and fascinating journey

From building over 45+ integrations at Productiv and Vessel, here are the top 5 problems we’ve observed from building in-house:

Problem 1: There’s always one more integration you’re missing

There’s a never-ending list of integrations your customers want that can block deals or result in a subpar user experience. Every company is different and often chooses a unique set of tools best suited for their business. However, building new integrations can be time-consuming and distracting, which can take engineering resources away from developing other features that differentiate your app.

Taking CRMs as an example. If you’re building a sales tool, integrating with your customer’s CRM is like plumbing in your house. You can’t skip it. The CRM (Customer Relationship Management) is used to track data about prospects and customers within any sales organization and is the source of truth for sales data. Depending on the industry, region, and size of your customers, the CRM chosen will differ vastly and the same applies to many other categories of tools. There will always be one more tool you’re missing and you wished you rolled it out quickly enough.

Problem 2: Integrations are extremely varied and no two integrations are alike

Don’t assume once you build out an integration that you can just reuse your code. The lack of standardization makes building reliable integrations quickly a difficult task. Here’s why:

OAuth 2.0 is a nonstandardized standard: OAuth 2.0 is an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications. The protocol itself has grown to over 16+ RFCs which makes it complex, comprehensive, and secure. Unfortunately, many companies forego the complexity by implementing only parts or different flavors of OAuth, which makes it a painstaking process to build authentication.

  1. Notion: Traditionally, OAuth uses “scopes” to control the permissions an integration has to perform actions on behalf of the connected user. Instead of the scopes standard, they’ve created a new concept known as capabilities.
  2. Salesforce: Every Salesforce account has a unique URL (e.g. vessel.my.salesforce.com) used for making API calls. This URL is not surfaced until after the user logs in to their account at the end of the OAuth exchange.
  3. RingCentral: Customers can choose to connect different types of accounts: sandbox or production. Depending on the account type, the URLs used for the OAuth exchange differ.
  4. Outreach: Across many apps, refresh tokens typically do not expire. However, refresh tokens for Outreach expire in 2 weeks if no API calls are made during that time window.

Rate limits: Rate limits play a large factor in the reliability of an integration. Once it is exhausted, you are not allowed to make any API calls to the downstream system until the limit is refreshed. The last thing you want is your customer asking you why something is broken.

  1. HubSpot: Rate limits differ depending on how a user was authenticated. For those connecting via an API token, there is a daily limit. For users connected via OAuth, it is based on a time window where you can only make 100 API calls every 10 seconds.
  2. Salesforce: Rate limits are shared by all integrations and resets daily. If the quota is exhausted, every integration connected to this account will be prevented from making any future API calls until the limit refreshes. For many businesses, an exhausted API quota can cause significant business damage given the number of systems that integrate with the CRM.

The examples above are only the tip of the iceberg. The right infrastructure is critical to shipping integrations quickly and reliably which can be built with an engineering team that understands integrations deeply. Without it, imagine racing in a plastic raft held together by duct tape while others are speeding away with their integrations on motorboats.

Problem 3: The time it takes to build a new integration can vary vastly between apps

Developer experience plays a large role in how long it takes to build a new integration. Developer experience is defined by how easy or difficult it is for a developer to perform essential tasks needed to implement a change. A poor developer experience can cause a large amount of confusion during the development process which can add weeks to your timeline. Here’s what we’ve seen:

Confusing documentation. Salesforce has 44 different APIs, but a majority of companies will only use 1 of them. Can you find which one it could be?

Outdated documentation: APIs are constantly changing and outdated documentation makes APIs unusable. For example, Pipedrive had an API that didn’t match their documentation and it took hours of trial and error to triage.

Missing SDK and static typing: SDKs are a powerful abstraction on top of APIs and provide a way for developers to quickly make API calls. Oftentimes, SDKs come with static typing which makes code less error-prone. However, not every company offers an SDK.d

Lack of developer community or support: If API documentation was a textbook, the developer (student) would still have questions. A lack of developer community or support can result in uncertainty during the development process.

Problem 4: APIs are constantly changing and require continuous upkeep

Integrations are critical workflows and should be treated at the same level of priority as any feature. APIs are constantly changing as companies continue to improve their product which can cause integrations to break. There are 3 types of changes we’ve observed:

  1. Improvements: These are typically backward compatible change and requires no maintenance.
  2. Breaking changes: An API is changing in a way that may not be backward compatible with your use case
  3. Deprecation: An API is being removed.

Engineers need to diligently monitor these changes to ensure that your integration continues to work reliably. Here’s one of the many emails I get about keeping these integrations up to date.

Problem 5: Lengthy app reviews can add months to your timeline

Many companies require a review before going live with your integration. The process differs across apps and can take anywhere from weeks to months. These reviews typically consist of the following three parts:

  1. A partnership review to determine whether the integration being built is beneficial to their business.
  2. A technical review to verify the quality of the integration you’ve built.
  3. (Required by some) A security review to test the security posture of your solution.

App reviews for companies like Google and Salesforce can take months, while Pipedrive and Salesloft can be accomplished in weeks. On top of the review process, you may receive feedback for changes that need to be implemented, which can add additional weeks to your timeline.

Integrations are a complex problem, can we do better?

Having the right infrastructure in place is crucial to building reliable integrations at scale. At Vessel, we are building a developer-first native integration platform for go-to-market tools that solves these problems. We help companies scale native integrations quickly across CRMs, Chat, Sales Engagement, Dialers, and more.

If you’re thinking about building new integrations at scale, happy to chat more at avery@vessel.dev!