Integration Error Handling: Where Failed Records Go to Be Found
An integration without proper error handling doesn't fail loudly, it fails silently, and silent failures are the ones that hurt.
The dangerous integration isn't the one that crashes, it's the one that quietly drops three records and reports success. Silent failure is the enemy. Proper error handling is what turns 'we lost data and don't know it' into 'we caught it and fixed it in an hour'.
Every failure needs a destination
A failed record goes somewhere you'll see it, a fault queue, an error table, an alert. Not into the void. If you can't answer 'where do failures land', you have silent failures waiting to happen.
Retry the transient, escalate the real
A network blip deserves an automatic retry with backoff. A malformed record deserves a human. Configure the difference so you're not manually rerunning things a retry would've fixed, and not endlessly retrying something that'll never work.
Log enough to actually diagnose
When something fails at 3am, the log is all you've got. It needs the record, the reason, the timestamp, enough to fix it without reproducing it. Skimpy logging turns a ten-minute fix into an afternoon.
Real scenario: a client's integration silently skipped records that failed validation. Weeks later they realised a batch of new starters never made it to a downstream system, no accounts, no access, angry people. We rebuilt with a fault queue and alerting. Failures now surface same-day. Loud failure beats silent failure every time.