Integration Mistakes That Cost Thousands
No error handling, no idempotency, no monitoring. The five most expensive integration errors we see repeatedly, ranked by how much damage they cause.
Integrations look simple on the diagram. System A talks to System B, data flows, everyone's happy. In practice, integrations are where a lot of unexpected cost hides, and where small mistakes compound into large problems.
Here are the mistakes I see most often, ranked roughly by how much they tend to cost.
The expensive mistakes
1. No error handling. The integration works great on the happy path. Then an API times out, a field is unexpectedly null, or a rate limit is hit, and the integration silently fails. Data goes missing, and nobody notices until a customer complains or the books don't reconcile.
2. No idempotency. If an integration retries a failed request, does it create a duplicate record? Double-charge a customer? Send the same email twice? A lot of integrations aren't built to handle retries safely, which means error recovery creates new errors.
3. Trusting the source data. Just because data comes from another system doesn't mean it's clean. Missing fields, wrong formats, unexpected characters, duplicate records. All of these flow through unvalidated integrations and corrupt your downstream systems.
4. No monitoring. If your integration fails at 2 AM, when do you find out? If the answer is "Monday morning when someone checks," you've potentially lost a weekend's worth of data. Monitoring and alerting aren't optional for production integrations.
5. Ignoring rate limits. Most APIs have rate limits. Ignoring them means your integration gets throttled or blocked during high-volume periods, exactly when you need it most.
Why they happen
These aren't obscure edge cases. They happen because integrations are often treated as simple "connect A to B" tasks rather than the mission-critical data pipelines they actually are. The initial build works fine; it's the failure modes that weren't planned for.
Preventing them
- Design for failure first: Before building the happy path, plan what happens when things go wrong.
- Make operations idempotent: Every operation should be safe to retry without creating duplicates.
- Validate at the boundary: Check data quality when it enters your system, not after it's already been processed.
- Monitor everything: Log requests, responses, and failures. Alert on anomalies. Review regularly.
- Test with real-world data: Not just perfect sample data. Test with messy, incomplete, edge-case data.
Good integrations are boring. They run quietly, handle failures gracefully, and nobody thinks about them. That's the goal.