The systems are fine. The seams between them are not.
Nothing in the stack is broken on its own. A lead arrives, and the thing that should have happened next depended on somebody noticing. Integration work is rarely about connecting two APIs — it is deciding what is true, who wins when two records disagree, and what happens when the far end is down.
Thirty minutes · no predetermined package
A quiet failure looks exactly like a quiet week.
Most connectors retry a few times and then give up without telling anyone. That is a reasonable default for a tool that does not know how much the data is worth, and a poor one for the path a paid lead travels down. The failure is not the outage; the failure is that nobody found out.
The other half of the work is agreement. When two systems both hold a customer, both are authoritative and neither is, and every automation built on top of them does the right thing for half the records. Naming which one wins — per object, in writing — is the decision the rest of the architecture follows from.
What this looks like from inside the business.
A lead arrives and nothing routes it until somebody notices.
Two systems hold the same customer and neither is authoritative.
An integration was built once, by someone who has left, and nobody knows what it syncs.
Data is re-keyed between systems, and the copies drift apart within a week.
When a sync fails, the first person to hear about it is a customer.
Reporting needs an export from each system and a reconciliation in between.
Four mechanisms, and none of them is the software.
No system of record was named
Both systems are authoritative, so both are wrong half the time. This single unanswered question causes more damage than any missing feature.
The integration has no contract
A field-by-field mapping made in a vendor UI, with no schema written down and no version. It works until one side adds a required field.
Failure is silent by design
Connectors retry a few times and give up quietly. Without a dead-letter queue and an alert, a broken seam is indistinguishable from a slow week.
Automation sits on unagreed data
Rules that fire on a field two systems populate differently will do the right thing for one half of the records and the wrong thing for the other, consistently.
Six questions before changing anything.
One way in, and every failure visible.
The point of an owned ingest endpoint is not throughput. It is that a failure has somewhere to land, and somebody to tell.
What we would actually be doing.
Where this has already been built.
Partner ingest, running synchronously
One endpoint, validation and dedupe before anything downstream, and a dead-letter queue that has a name on it.
See the architectureWhat an integration contract should say
The fields, the match key, the retry policy and the person the dead-letter queue wakes up.
ReadHow we take over an existing stack
Reading what the connectors actually do before changing any of them, and what we do about the ones nobody can explain.
How we workWhat teams ask before they start.
Can you work with the integration platform we already pay for?
Yes, and often that is the answer. Zapier, Make and native connectors are appropriate for work that is allowed to fail quietly. Where a failure costs a lead or corrupts a record, we would rather own the endpoint and be able to show you the queue.
Do we have to replace anything?
Usually not. The seams are the work. If a system genuinely cannot expose what the others need, we will show you the specific call it does not support rather than asserting that it is the wrong tool.
How do you handle duplicates?
By deciding the match key before writing any code, and by making the write idempotent so that a retry cannot create a second record. Most duplicate problems are retry problems that were never designed for.
What happens when a platform changes its API?
The contract is written down and monitored, so the change surfaces as a failing check on our side rather than as a customer complaint on yours. Deprecation notices are tracked; that is part of what ongoing support is for.
Who runs this once it is live?
Whoever you decide. If it is your team, the runbook and the alert routing are handed over with the build. If it is us, that is scoped explicitly rather than left implied.
What is system integration?
Making separate systems behave as one, which is mostly a set of decisions rather than a set of connectors: what is true when two records disagree, which system wins, what happens to an event nobody consumed, and how a failure becomes visible. The plumbing is the easy part and almost never the part that fails.
What is a system integrator?
A firm that takes responsibility for the seams between systems rather than for any one of them. The useful test is whether they will own the failure: if a lead is dropped between the form and the CRM, an integrator answers for it, while two platform vendors each explain that the problem is at the other end.
How do you integrate several CRM systems into one application?
By deciding on a system of record per entity before writing anything — one CRM owns the contact, another may own the deal — then reconciling on a business identity rather than an internal id. Merging several CRMs without that decision produces one larger set of disagreeing records.
Tell us where the handover breaks.
Usually one seam is doing most of the damage. Describe what arrives and where it stops, and we will tell you what we would look at first.