Custom integrations between systems: when do you need custom work?

Developer working on two screens side by side

You have two systems that need to talk to each other. You look for a standard integration in Zapier, Make or your software's app store, and it turns out not to exist. Or it does exist, but does not quite do what you need. Then the question arises of whether to have an integration built. Sometimes that is the only good route, sometimes there is a simpler solution. Below you will read how to tell the difference.

What is a custom integration?

A custom integration is a connection between systems that is built specifically for your situation, instead of a ready-made connector. It can be small, such as a script that moves orders from one system to another every night. It can also be a middle layer that retrieves data from several systems, translates it, checks it and passes it on, with its own logic and error handling.

Such an integration almost always runs via the APIs of the systems involved. What APIs are and what you can do with them is a topic in its own right.

When is a standard integration not enough?

Standard integrations via Zapier or Make work excellently for many situations, and where possible we recommend them. They hit their limits when:

your software is not supported. Industry software, Dutch packages and internal systems are often missing from the catalogue of standard tools.
data needs to be processed. Not one field to one field, but merging, converting, validating or translating.
the volumes are large. Thousands of records a day run into limits and task costs.
the logic is complex. Exceptions, conditions and branches quickly become unclear in a visual flow.
there are requirements for security or logging. Some data may not pass through external services, or you need to be able to show exactly what happened when.

What should you check before having an integration built?

The first question is always whether the software has an API. Without an API you depend on exports, imports or manual work. With an API, virtually any integration is possible.

This is how you check:

Search for the name of the software with "API" or "developer documentation".
Ask the vendor. Not every API is publicly documented, sometimes access is on request.
Check your subscription. API access is sometimes only included in a higher plan.

If there is an API, look beyond the fact that it exists. Can you only read data or also write it? Are the fields you need available? How many requests can you make per minute? And is the documentation usable? Those answers determine whether an integration is simple, difficult or not feasible.

What routes are there to integrate?

An automation tool with HTTP requests

Even if Make or Zapier does not know your software, you can call any API via an HTTP module. For simple integrations with a few steps that works well. With many steps, conditions and error handling it quickly becomes unclear and hard to maintain.

Your own middle layer

For more complex integrations we build a middle layer, for example with Supabase or Xano, or as a server function on Vercel. That layer retrieves data, processes and checks it, stores a copy where needed and offers its own clear API to your website or application. All the logic sits in one place, and that makes management simpler.

Which route fits depends on the volume, the complexity and who will manage the integration later.

What does it involve?

A good integration is more than code that moves data.

Analysis. Which data, which direction, how often, and what are the exceptions?
API research. This is sometimes where it already turns out that something is more complex than expected, or that a field is simply not available.
Build and test. With real data and real exceptions, not just the ideal path.
Error handling. What happens if a system is temporarily unreachable or a record is invalid?
Monitoring. You want to know immediately when something goes wrong, not only after a week without data.
Maintenance. APIs change. An integration needs someone to keep it up to date.

A typical situation

An organisation works with a scheduling system for its field service. Good software, but without standard integrations. Customers call to reschedule their appointment, and that costs the team a lot of time. The scheduling system does have an API.

The solution: a middle layer that retrieves appointments from the scheduling system and offers them via its own API to a client portal. Customers see their appointment there and can reschedule it. Changes go back to the schedule via the same route. The team has to make fewer calls and everything stays in sync.

What determines the investment?

A custom integration costs more up front than a standard integration you set up in an hour. On the other hand, standard tools charge per task, so ongoing costs can rise considerably at high volumes. Your own integration has higher build costs and low ongoing costs. Where the tipping point lies depends on:

the number of systems and endpoints
the amount of processing on the data
the volume and the required speed
the quality of the APIs
the requirements for logging and management

If the standard tool cannot do what you need, that comparison is not relevant. Then it is about what the integration delivers in time and fewer errors.

When is it better not to?

Custom work is not always the answer. Sometimes it is wiser to adapt your process so that the integration is not needed. Sometimes it is time for different software, especially if your current package has no API and the vendor is not going to build one. And if something only happens a few times a month, manual work is sometimes simply cheaper.

That is why we always start with the question of whether it can be done with standard tools. If not, we build the integration with a clear plan and management after delivery. Read more about our system integrations or about workflow automation, or ask us to take a look.