Integrations rarely fail with a bang. They fail quietly. An order sync stops on a Thursday afternoon, nobody notices, and on Monday a customer calls asking why their shipment never left. By then you're not fixing an integration — you're doing archaeology across three systems, trying to figure out which records made it and which didn't.
The uncomfortable truth is that most integration projects budget generously for the happy path and almost nothing for what happens when things go wrong. The connector gets built, the demo works, everyone signs off. Error handling becomes something you discover you needed after the first bad weekend.
Three Kinds of Failure, Three Different Responses
Lumping every error into one "integration is down" bucket is why teams stop trusting their alerts. There are really three categories, and each deserves different treatment.
Transient failures are network timeouts, rate limits, a system rebooting during a maintenance window. Nothing is actually wrong with your data. These should retry automatically with increasing delays between attempts, and they should never wake anyone up unless they keep failing.
Data quality failures are the messy middle: a record with a missing tax ID, a product code that doesn't exist in the destination system, an address that fails validation. Retrying won't help — the same bad record will fail the same way forever. These need to land somewhere a human can see them, fix them, and reprocess them.
Business rule failures are the ones worth paying attention to. An invoice that won't post because the customer is over their credit limit. An order that can't ship because inventory went negative. These aren't technical problems at all. They're operational decisions that surfaced through a technical channel, and they need to reach the person who can actually make the call.
When you separate these three, your alerting gets dramatically quieter and dramatically more useful.
Retries Need a Memory
Automatic retries are the right default for transient errors, but only if your integration is idempotent — a plain-language way of saying that processing the same message twice produces the same result as processing it once.
Without that, retries create their own disaster: duplicate invoices, double-counted inventory, customers charged twice. The fix is usually straightforward. Every message carries a unique identifier, and the receiving system checks whether it has already seen that identifier before acting. It's a small amount of upfront design work that prevents an entire category of cleanup projects.
Also worth deciding early: how many times do you retry, and what happens after the last attempt? A message that has failed five times shouldn't disappear. It should move to a holding area — often called a dead-letter queue — where it sits visibly until someone deals with it. A failed record you can see is an annoyance. A failed record that vanished is a liability.
Someone Has to Own the Queue
This is where most integrations fall down, and it isn't a technical problem. The error queue exists, it's populated, and nobody has been told it's their job to look at it.
Give it an owner in operations, not engineering. The person fixing a missing customer address doesn't need to understand APIs — they need a screen that shows what failed, why in plain English, and a button to try again after they fix it. If your only way to reprocess a failed record is to file a ticket with a developer, the queue will grow until everyone learns to ignore it.
A workable setup looks like this:
- A daily review of anything sitting in the error queue, with a named owner
- Error messages written for operators, not stack traces
- Self-service reprocessing once the underlying data is corrected
- An escalation path when the same error repeats across many records — that's a pattern, not an exception
Reconciliation Catches What Alerts Miss
Alerts tell you when something threw an error. They don't tell you when something quietly did nothing. A connector that stops polling doesn't generate errors — it generates silence, which looks identical to a slow day.
The protection is a simple count comparison. Orders created in the webstore yesterday versus orders received in the ERP. Invoices posted versus invoices synced to the accounting system. Run it nightly, and alert on the gap rather than on the errors. It's unglamorous and it catches the failures that hurt most.
Design for the Bad Day
Every integration will have a bad day. Systems get upgraded, APIs change, someone imports a spreadsheet with unexpected characters. The difference between a minor inconvenience and a week of manual cleanup comes down to whether anyone planned for it.
If your systems are connected but you've never seen an error queue, don't know who owns it, or find out about sync failures from customers, that's worth a conversation. Infraxio builds integrations between ERP, CRM, and web platforms that are designed to fail visibly and recover cleanly — reach out and we'll walk through what your current setup would do on its worst day.