API integration rescue for an existing system
Short answer: A failing API integration should be audited before anyone keeps patching it. The right decision depends on whether the problem is a small mapping issue, a missing control layer, or a broken system design.
What a failing integration looks like
The visible symptoms are usually easy to describe:
- Records sync sometimes but not always
- Failed records are invisible until someone complains
- Duplicate orders or invoices appear
- Stock updates are late or wrong
- The integration breaks after a small setting change
- Staff keep a spreadsheet to "double check" the integration
- The original developer is no longer available
These problems are not just technical. They damage trust in the system. Once the team stops trusting the integration, they start working around it.
The rescue audit sequence
We do not start by rewriting code. We start by finding the failure pattern.
- Map the intended flow. What was the integration supposed to do?
- Map the real flow. What are staff doing outside the system?
- Collect failed samples. Wrong records, duplicates, missing records and timing issues.
- Inspect logs and payloads. Confirm whether the error starts at source, middleware or destination.
- Check source-of-truth rules. Identify which system owns each field.
- Review validation. Find which bad records should have been blocked.
- Decide patch, stabilise or rebuild. Choose the lowest-risk path based on evidence.
This is the integration-specific version of an ERP rescue and system audit.
Patch, stabilise or rebuild
| Finding | Best path |
|---|---|
| One mapping error | Patch and test a controlled batch |
| Missing logs | Add logging before changing business logic |
| Duplicate posting | Add idempotency and unique external references |
| Bad records entering the destination | Add validation and an exception queue |
| Workflow assumptions are wrong | Redesign the flow before coding |
| No code or access available | Rebuild the integration around documented rules |
The goal is not to rescue bad code at all costs. The goal is to protect business operations with the least risky fix.
Why rescue often becomes workflow redesign
Many integrations fail because they were built around a data transfer, not a process. For example, "send order to ERP" sounds simple until returns, partial deliveries, branch stock, customer-specific pricing and approvals appear.
When those rules are real, the integration needs a workflow layer, not just a script.
FAQ
Can you rescue an integration without the original developer?
Sometimes. If the code and credentials are available, takeover is easier. If they are not, we can still audit the current workflow and design a replacement integration.
How do we avoid breaking live operations during rescue?
We isolate the risky sync path, test with limited records, and avoid mass changes until the failure pattern is understood.
Is it cheaper to patch or rebuild?
It depends on whether the original design is sound. Patching is cheaper only when the failure is narrow and the integration is maintainable.
Audit My Integration