What keeps an integration running
Building is the easy part. An integration that only works when everything goes well is not an integration. The difference is in error handling, logging and monitoring — and in who gets called when a certificate expires or a password changes.
The four parts
- Error handling
- A record that does not add up is set aside and reported; the rest carries on. Halting at the first deviation costs more work than it saves.
- Logging
- Afterwards it must be visible per record and per run what was processed and what was not. Without a log every discussion is unresolvable.
- Monitoring
- An integration doing nothing goes unnoticed — until the month-end close. Alerting on absence matters as much as alerting on errors.
- Repeatability
- A run has to be repeatable without creating duplicate entries.
What goes wrong in practice
- Expired certificates
- The classic cause of an integration stopping on a Saturday. Expiry dates belong under monitoring.
- Changed passwords
- An account change on the other side brings everything to a halt. Prefer keys or service tokens.
- A package update
- Fields change, new mandatory data appears. Sticking to the interface limits the damage.
- Unexpected data
- An empty postcode, a negative amount, a duplicate line. The integration should report those, not process them blindly.
We keep an eye on the integrations we build, so you do not find out through an empty ledger.
More on this →