Why integrations fail silently
A broken screen is reported in minutes. A sync that stopped writing to the ERP three weeks ago is discovered at stocktake — after twelve hundred orders reconciled wrong. That gap is what makes integration failures expensive.
Integrations fail silently because nothing is watching for absence. Monitoring catches errors, but a stopped sync produces no errors — it produces nothing at all. The fix is to alert on missing expected traffic and run a scheduled reconciliation that proves both systems still hold the same records.
Five ways integrations go wrong
Every integration we have been called in to rescue failed in one of these five ways. Each has a known engineering answer — the only question is whether it was built in at the start or left out.
1. The double-processed webhook
The sender times out waiting for your response and retries. Your system creates the order — or issues the refund — twice. This is not an edge case: Stripe, Shopify and most carrier APIs retry by design, and a slow database query is enough to trigger it.
The fix: idempotency keys, recorded before processing. Every inbound event carries a unique identifier that you store the moment it arrives. A repeat delivery is recognised and acknowledged without re-running the work. This is a handful of lines and it eliminates an entire class of duplicate-record bugs.
2. The silent stop
A token expired in March. Nothing alerted, because nothing failed loudly — the integration simply stopped being called. Nobody noticed until someone asked why April's numbers looked light.
The fix: heartbeat monitoring plus scheduled reconciliation. Alert on the absence of expected traffic, not just on errors. Then run a nightly job that compares record counts and checksums on both sides. Silence is not evidence that data is flowing; a reconciliation job that finds nothing is.
3. The partial write
An order is created in system A, the call to system B fails, and now the two disagree with no record of why. The user saw a success message. Support finds out a fortnight later.
The fix: a durable queue with dead-letter handling. The event survives the failure and retries with exponential backoff. Anything that still cannot be processed lands in a dead-letter queue that a human can actually see and act on — not a log line nobody reads.
4. The version that moved
The vendor deprecated v2 of their API. The notice went to an inbox belonging to someone who left in 2024. The integration worked right up until the sunset date, then stopped.
The fix: pin the API version explicitly, run contract tests nightly against the live sandbox, and route vendor notices to a team address. Contract tests catch a changed response shape days before it reaches production.
5. The field that meant two things
"Reference" is the purchase order number in one system and the invoice number in the other. Both teams are certain they are right. The data flows perfectly and is wrong in a way no error can detect.
The fix: a written field map agreed before any code. Which system is authoritative for each field, and what happens when they conflict. Most integration failures are ownership disputes, not technical faults.
Four of these five produce no error at all. If your integration monitoring only watches for exceptions, it is watching the one failure mode that rarely happens.
Choosing the right pattern
Picking the wrong integration pattern is how a simple connection becomes a permanent maintenance cost. Four patterns cover almost everything.
| Pattern | Use when | Avoid when |
|---|---|---|
| Synchronous API call | The user is waiting and needs the answer now — card authorisation, stock check at checkout | The other system is slow or unreliable; you are now only as available as they are |
| Webhook + queue | The other side pushes events — payments, shipment status, form submissions | Strict ordering matters and the sender does not guarantee it |
| Scheduled batch | High volume, no urgency — nightly catalogue, daily financial posting, EDI runs | Users expect near-real-time and will call support about it at 11am |
| Event bus / streaming | Several systems need the same event and the list will grow | You have two systems and no plans for a third — it is overhead you maintain forever |
Scroll the table sideways for the full comparison.
The mistake we are most often called in to undo
A synchronous call to a third-party API inside the checkout path. It works perfectly in testing. Then the provider has a slow morning and your checkout starts timing out alongside it.
Anything not strictly needed to answer the user belongs in a queue. The order is accepted, the downstream write happens behind it, and a failure there becomes an alert rather than a lost sale. This single change has more impact on revenue than any amount of retry tuning.
What a healthy integration ships with
- A dashboard showing throughput and failure rate, visible to operations rather than only to engineers
- Alerting on failure rate and on queue depth and on unexpected silence
- A dead-letter queue with an owner and a review routine
- A scheduled reconciliation report proving both sides agree
- A written runbook for the top three failure modes
- Pinned API versions with contract tests running nightly
If an existing integration is missing these, the first step is not to fix the code — it is to add the visibility, so you can see the real failure rate before and after any change. That approach is described on our API and system integration page.
Related reading
Which two systems disagree, and who re-keys the difference?
That is the whole brief. Tell us the systems and the field they argue about, and an engineer replies within one business day with the pattern we would use.
- Email — contact@canopussoft.com
- Phone / WhatsApp — +91 817 979 7732