01
One-way feed
One system is the source of truth and the other follows. Simplest and most reliable. If you can arrange the problem this way, do — most conflicts stop existing.
Two systems. Both hold the truth. They disagree.
Systems integration means connecting software that was never designed to work together, so data entered once appears correctly everywhere it is needed. The technical part is rarely the hard part. Deciding which system wins when they conflict, and making failures visible, is where these projects are won or lost.
Patterns
Four shapes this takes.
02
Two-way sync
Both sides can change a record. Considerably harder, because now you need a written rule for what happens when both change the same field before the sync runs.
03
Events and webhooks
Something happens over there, and something should happen here, promptly. Needs care about duplicates — most systems will send you the same event twice eventually.
04
An API of your own
When other people need to connect to you — a customer’s system, a partner, your own mobile app. Designed to be versioned, so changing it later doesn’t break them.
The part people skip
Integrations fail quietly. That’s the danger.
A broken sync does not produce an error anyone sees. It produces two systems drifting apart, and a reconciliation project three weeks later. So the unglamorous half of this work is the half that matters.
A written rule for which system wins a conflictDecided up front
Retries with backoff when the other end is downStandard
Duplicate events handled without double-processingStandard
An alert on failure — and on unexpected silenceStandard
A log you can read to answer “what happened to this record”Standard
Questions
Asked most often.
What is systems integration?
Systems integration is making separate pieces of software share data reliably, so a fact entered in one place appears correctly in the others without a person copying it. In practice it covers API connections, scheduled syncs, webhooks and file transfers, plus the far less glamorous work of deciding which system wins when the two disagree.
What if one of our systems has no API?
It is more common than vendors admit, and there is usually still a route: a scheduled export, a database replica, a file drop, or in the worst case a controlled automation of the interface itself. Each is progressively more fragile, and we will tell you plainly which one you are getting and what will break it, rather than presenting a brittle option as a solid one.
How do we know when a sync has failed?
Because it tells you. The characteristic failure of integration work is silence — the sync stops, nobody notices for three weeks, and by then two systems have drifted badly enough that reconciling them is a project. We build alerting on failure and on suspicious silence, so a broken sync is a message on the day it breaks rather than a discovery at month end.
Should we use Zapier or something similar instead?
Often, yes, and we will say so. For simple, low-volume, non-critical connections those tools are cheaper and faster than anything custom. They stop being the right answer when volume makes per-task pricing painful, when a failure needs real handling rather than a retry, or when the transformation between systems is complicated enough that it belongs in code you can test.
Which two systems, and who reconciles them?
Name them and describe what gets copied by hand. That’s usually enough for us to tell you what it would take.