“Salesforce is broken” is rarely a useful debugging statement.
Complex journeys cross systems. Each system can be individually healthy while the overall path still fails because one side sends something the other side does not expect.
That is why I start with the boundaries: what leaves system A, what system B expects, what evidence confirms the handoff and who owns each side.
The questions are simple.
This is useful beyond APIs.
A browser loading an embedded form is a boundary. A file import is a boundary. A warehouse sync is a boundary. So is a human approval that must happen before development can proceed.
The pattern is the same: define the contract, observe both sides and stop using the end symptom as the diagnosis.
The practical rule.
Draw the path as boxes and arrows. Then replace each arrow with a question: what must cross here, how do we know it crossed and what happens if it does not? Debug the arrows before blaming the boxes.