Two systems, finally talking: what a real integration needs
There is a person at your company whose job, three times a day, is to open two browser tabs and retype things from one into the other. Orders into fulfillment. Leads into the CRM. Invoices into accounting. They are good at it, they have a system, and they are also a single point of failure, a source of typos, and the reason nobody knows what happened to order 4471.
Automating that is a week of work. Automating it correctly is the same week done in a different order, and the difference is entirely in four unglamorous details.
Retries, duplicates, mismatches, and silence
Every integration that has ever caused a 2am incident failed at one of these. They are not advanced topics. They are the whole job.
- 01Idempotency, or you will double-charge someone.
Networks fail after the write and before the acknowledgement. If the same message arriving twice creates two orders, it is not a question of whether that happens, only when. Every record needs a stable external id, and every write needs to be an upsert on it.
- 02Retries with backoff, and a dead-letter queue.
The other system will be down, rate-limited, or slow. Retry, spaced out, a bounded number of times — then park the message somewhere a human can see it and replay it. “Retry forever” is a denial-of-service attack on your own vendor.
- 03A reconciliation pass, because events get lost.
Event-driven syncing drifts. A nightly job that compares both sides and reports differences is fifty lines of code and the only thing that will ever tell you the sync is wrong before a customer does.
- 04Logs a non-engineer can read.
Not a stack trace. A per-record trail: what arrived, what was sent, what came back, when. The first question anyone asks is “what happened to order 4471,” and answering it in ten seconds is the difference between a tool people trust and one they check by hand anyway.
The mapping is a business decision, not a technical one
The code that moves data is small. What takes the time is the questions only your team can answer, and they are always the same questions:
- Which system wins when the two disagree about a customer's address?
- What happens to a record that fails validation — park it, drop it, or fix it and write it anyway?
- Is a cancelled order in system A a deleted order in system B, or a status change?
- What about the seven years of existing records that were entered by hand, inconsistently?
- Who gets told when something lands in the dead-letter queue, and by what channel?
Get those answered before any code exists. Written down, five lines, in the issue. They are the acceptance criteria, and an integration built without them will be technically correct and operationally wrong.
When a no-code connector is the right answer
Zapier, Make and the rest are genuinely good products, and for a lot of flows they are the correct choice. The line is not about scale or sophistication — it is about how much the flow matters.
| No-code connector | Code you own | |
|---|---|---|
| Volume is low and predictable | Yes | Fine |
| A duplicate would cost real money | No | Yes |
| The mapping has conditional logic | Barely | Yes |
| You need per-record history you can query | No | Yes |
| Anyone on the team should be able to change it | Yes | Through you |
| It runs while nobody is watching | Risky | Yes |
The failure mode of connectors is not that they cannot do it. It is that they hide the four details above. A task that silently stopped running three weeks ago looks exactly like a task with nothing to do, and you find out when the numbers do not reconcile at month end.
Ship it read-only first
- 01Read from both sides and write nothing.
Day one produces a report: here is what the two systems currently disagree about. That report is usually the most surprising artifact of the whole project.
- 02Write in one direction, for one record type.
The highest-volume one. Narrow scope keeps the blast radius small while you find out what the real data looks like.
- 03Run it beside the human for a few days.
They keep doing it manually; you compare. Every disagreement is a mapping rule nobody mentioned.
- 04Turn off the manual path and keep the reconciliation job.
The person stops copying. The nightly comparison stays forever — it is what makes the automation trustworthy rather than merely fast.
The goal is not that the sync never breaks. It is that when it breaks, you know within a day and can replay exactly what was missed.
Handled this way, the person who was the integration gets their Tuesday back, and the process becomes something you can audit instead of something you hope about. That is the real deliverable — not the automation, the auditability.
One week, one agreed deliverable: the sync, the reconciliation job, and a log your ops lead can read. In your repo by Friday.
See how the free week works →