An error handler only catches what the API admits is an error.
Some APIs admit nothing.
The setup: a scheduled scenario creates an invoice through an accounting API, sends the document to the customer, then writes the document number back to a sheet as the duplicate guard.
What I assumed: if the document is not created, the module fails, the error handler fires, I get an alert.
What actually happened: the API returns HTTP 200 on a rejected document. The rejection lives in the response body, in a status field, with a reason string like “create document failed” or a mismatch between the total and the payment amount.
So the module succeeded. The chain continued. Nothing was created.
The customer got a document URL that resolved to nothing, and the run looked perfectly clean in the history.
No error handler in the world fires on a 200.
The fix is two lines of configuration.
1. Filter on the response body, not the status code.
The chain continues only if the body’s own status field is true AND a document number actually came back.
2. Never write the reference number on a failure.
Because the sheet still shows the row as unissued, the next scheduled run picks it up and retries on its own. No duplicate, no missing document, and no human has to remember anything.
The alert carries the reason string from the body, so I know whether it was a rounding mismatch or a network problem without opening anything.
How to check this on your own scenarios: take any HTTP module that creates something and look at what it returns on failure. If the failure is described inside a 200, your error handler is decorative.
Verify the outcome, not the acceptance.
Credentials and client data are redacted in both screenshots.