Integration

What is an integration: the term explained for the people who have to build one

An integration is a working connection between two systems that lets data or an action pass from one to the other without a person retyping it, so a record created in one place arrives, correctly shaped, in the other. It replaces a manual handoff with a defined one.

The word stretches from a nightly file drop to a live two way sync. What separates those is rarely the technology. It is who starts the exchange, how often, and what is supposed to happen when it fails.

What does integration mean in practice?

Almost nobody has an integration problem in the abstract. They have one specific handoff that a person is currently doing by hand: copying a reference number, downloading an attachment, re-keying an address into the system of record.

An integration removes that step. The useful question is never whether two systems can talk, because with an API almost any two can. It is which system owns the record, and what the other one actually needs from it.

The scale of the gap is well documented. MuleSoft's 2025 Connectivity Benchmark Report, based on interviews with 1,050 IT leaders, found the average enterprise runs 897 applications, and that only 2% of IT leaders say more than half of their applications are integrated. The share of applications not fully connected has sat at roughly 71% for three years running.

How does an integration work?

Nearly every modern integration is assembled from two primitives, and choosing between them is the first real design decision:

• You ask. Your system calls the other system's REST API and requests data, on a schedule or on demand. Right for backfills, reconciliation, and anything where you want to control the timing.
• They tell you. The other system sends a webhook to a URL you registered, the moment something happens. Right for reacting to events without polling every few minutes for a change that comes once a day.

Authentication, rate limits, retries, ordering and signature verification all belong to those two mechanisms, and both entries cover them properly. Most production integrations use the pair together: a webhook announces the event, an API call fetches the full record it refers to.

What sits around the primitives is where the effort actually goes. Field mapping, because the two systems will not agree on what a status is. Transformation, because one sends a date as a string and the other wants an epoch. Error handling, because the receiving system will be down at some point. And somewhere for a human to see what failed, which is the part most often left out.

Integration explained: a case that opens itself

A field service team receives a completed visual submission. A webhook fires, the ticketing system creates a job, and an API call pulls the transcript, the answers and the media links into the job record.

The engineer never opens a second tool. If the ticketing system is unreachable, the event is retried for an hour and then lands in a failure queue that a named person checks, rather than disappearing quietly, which is what happens when nobody designed for the failure.

How integration differs from automation, migration and an export

• Automation is about triggering work: when this happens, do that. An integration is about moving the data the automation acts on. Automation without integration ends up acting on a stale copy.
• Migration is a one time move of history from an old system to a new one. It runs once, under supervision. An integration runs forever, unsupervised, which is a completely different reliability requirement.
• An export is a file a person downloads. It is not an integration, however regularly someone remembers to do it, because the process depends on that person remembering.
• An SDK is a convenience wrapper around an API in your language. Useful, but it does not decide any of the questions below for you.

What to settle before you commit

• Source of truth. Which system wins when the two disagree. Answering this late is how you get a sync loop that overwrites the same field twice a minute.
• The joining identifier. Which stable key links a record on one side to a record on the other. Email addresses and names are not stable keys.
• Failure behaviour. Retry policy, dead letter queue, and who gets alerted. An integration nobody is alerted about is an integration that has already been broken for a week.
• Volume and shape. Ten events a day and ten thousand are different builds. So is a 4 MB video file versus a 400 byte JSON payload.
• Access and retention. What the connecting account is allowed to read, how long the data is kept on your side, and how that is reviewed.
• Ownership after go live. An integration is a small piece of production software. Someone has to own it when the other side changes their API.

Where the connection runs through a broker rather than directly between the two systems, you are looking at middleware, which has its own trade offs. And where an integration ends is usually a queue a team works from, so decide who is meant to act on the record once it lands.

Visual capture tools sit at the front of this pattern, since a submission has to reach the system where the decision is made. Venta Capture, a product of VentaVid, exposes a REST API and webhooks for that, alongside auto forwarding of completed cases to a CRM or ticketing system.