Debugging an Integration: From Symptom to Root CauseDebugging an Integration: From Symptom to Root Cause

Reports arrive as symptoms, not problems: the data did not come through. Between that sentence and the cause sit many layers. Guessing at one at random burns time; checking them in order is almost always faster even though it feels slower at the start.

The order to work in

1. 01Reproduce it. If you cannot repeat it, there is nothing to fix yet. Note the exact data, the user, the role and the time.
2. 02Find the boundary. Where does the data stop? Did it leave the source system, or was it never sent? This halves the problem space immediately.
3. 03Check one layer above the stopping point. If data did not arrive, did the request arrive? Read the receiver's log, not the sender's.
4. 04Call it manually in Postman with the same data. This separates a code problem from an endpoint or credential problem.
5. 05Compare against a case that worked. Look for the single difference that explains it — usually an empty field, a special character, or a value longer than expected.
6. 06Fix it, then repeat step one to prove the symptom is gone.

Causes that keep coming back

• Environment mismatch — the code is right but points at Sandbox while the data lives in Production.
• Data nobody anticipated — nulls, zeros, quote marks, or text far longer than its column.
• Date format and timezone differences — a transaction lands a day early.
• Decimals and rounding — totals differ by a few units between source and target.
• Permissions — works when an administrator tests it, fails for the actual user.
• The process ran twice — data sent in duplicate because nothing made it idempotent.