Custom API integration: here’s what you need to know

As your organization looks to build either internal or customer-facing API integrations, you’ll often need to sync custom objects and fields.

The process of building and maintaining these custom integrations can be time-intensive and complex, which can make the process of scaling them difficult.

We’ll further explore the challenges of implementing and overseeing custom API integrations, break down several examples of how they can work, and then go on to explore your options in building any. But first, let’s align on the definition of a custom API integration.

What is a custom API integration?

It’s any API-based integration that syncs non-standard objects and fields in order to meet specific integration requirements. These integrations can either be built between internal applications or between your product and clients’ applications.

Related: What is a custom integration?

Custom API integration examples

To help make our definition more tangible, let’s break down some examples of custom API integrations. 

Note: Our first example will be an internal integration and our second example will be a customer-facing integration.

Syncing customer satisfaction scores with your CRM

Let’s imagine that you use a survey tool to gather customer feedback at regular intervals (e.g., every 3 months). 

As part of these surveys, you ask customers how happy they are through a specific rating scale and then ask them an open-ended question around why they gave that rating. 

You’d like to add each client's answers to these questions in their associated account in your CRM. That way, the account owner can quickly discover the rating, the reason behind it, and then respond accordingly.

To help facilitate this, you can build a custom API integration that works as follows: Any time a client completes the survey, their score and open-ended response on their score get added to custom-built fields in the client’s associated CRM account, which you refer to as “CSAT rating” and “CSAT rating explanation.”

Syncing candidate fit ratings in clients’ ATSs

Say you offer a candidate sourcing tool that helps clients identify candidates for certain open roles.

Every candidate your product recommends comes with a “Candidate rating” field that specifies the candidate’s level of fit for the role.

To help your clients' recruiting teams access this rating for every candidate they’re evaluating, you can integrate your product with clients’ ATSs and build the following sync: Any time a new candidate gets recommended and has a certain rating, their profile gets added to the associated client’s ATS (which includes the candidate's rating).

Related: Internal and customer-facing examples of API integration

The challenges of building and maintaining custom API integrations

The process of building out custom API integrations can prove more difficult than you might expect. Here are some of the challenges to look out for:

Mapping fields between systems can be complex 

With standard data types, the process of mapping fields is often fairly intuitive. For instance, an “Account” in a CRM can be mapped with a “Customer” in the ERP system. 

But when you start dealing with niche fields, determining the corresponding fields in other applications can become subjective and might even require you to add new fields in those applications. For example, if your customer success tool uses a custom “Customer Health Score” field that you’d like to map to your CRM, you might need to add the field to the latter before building the sync.

Requires custom-built data transformations

Your developers might have already built the data transformation logic for standard objects and fields. Using custom objects and fields requires them to add additional logic, which can be time intensive, especially if you need to build several custom integrations. 

Additional integration maintenance work

Custom integrations can introduce new errors for your team (e.g., the custom transformation logic starts passing incorrect data between applications). Your developers will, as a result, need to build additional error-handling processes that account for these issues. Moreover, these integrations (like any) will need to be updated over time as the business processes they support evolve. 

Managing this additional proactive and reactive work successfully can be a significant burden to your developers over time.

Related: Challenges of building API integrations

How to build custom API integrations

You generally have two options: building the integrations in-house and using a 3rd-party integration solution.

Since APIs differ in significant ways from one provider to the next—from their rate limit policies to their approaches to paginating responses to their methods of authenticating requests—each custom integration build is inherently unique and complex. In addition, many popular types of software are often highly customized (e.g., CRM systems), making several of your integrations all the more difficult to setup and sustain for your developers.

In the context of customer-facing integrations, a unified API solution can help. 

The platform normalizes the 3rd-party APIs' data models to a standard schema, allowing you to interact with the integrated data more easily. Also, you’ll only need to worry about the unified API platform’s rate limit, approach to pagination, and authentication method, which further simplifies the integration build and any of the maintenance and management work involved afterwards. 

Finally, using Merge, the leading unified API solution, you and/or your clients can use Field Mapping to add custom objects and fields to Merge’s Common Models (Merge’s normalized data models for its software categories) to build highly-custom, customer-facing API integrations with ease.

‍

Learn more about Merge and how you can use the platform to build customizable API integrations at scale by scheduling a demo with one of our integration experts.

Custom API integration FAQ

In case you still have any questions on custom API integrations, we’ve addressed several more frequently-asked ones below.

What is needed for custom API integrations? 

At the most basic level, you need to know the endpoints that correspond to the objects and fields you want to connect to and either use a tool or rely on in-house developers to build and maintain the connections to these endpoints.

That said, since every custom API integration has unique requirements, sometimes you’re best suited to leverage in-house developers while in other cases it can make more sense to use a specific 3rd-party solution.

What are the benefits of custom API integrations?

The benefits largely align with the benefits of API integrations more broadly. 

In the case of internal custom API integrations, these include time savings, improved employer satisfaction, happier customers, and fewer human errors. And for custom API integrations that are customer-facing, you can experience higher customer retention, an improved close rate, and an easier path in expanding to more markets.

What is the difference between an API and a custom API?

Standard API endpoints offer the same set of data and functionality for any consumer, while custom API endpoints can be tailored to a specific client or subset of clients. The vast majority of organizations provide and consume standard API endpoints.

What is the difference between a custom integration and a custom API integration?

The only difference is in the method of connectivity that’s used. Like its name implies, custom API integrations only use API endpoints, while custom integration can also rely on files, screen scraping, among other approaches.

What are the different types of custom API integrations?

As our examples showed, there are seemingly endless types of custom API integrations spanning different teams, applications, and data. Moreover, these integrations can be internal (i.e., between your organization’s applications) or customer-facing (i.e., between your product and your customers’ applications), which only increases the types of API integrations that can be built.