An HTTP 200 can still hide a broken integration.

Two AI-assisted, self-built demos show why I test both the request and the result:

n8n retries: a transient 429 recovered on the second attempt. But the same fixed retry setting also retried a 401 three times. A retry limit can prevent endless attempts; it does not make every error retryable. The five-case report documents that limitation and the exact n8n version.

API pagination: page "1" + 1 became "11". The request succeeded, but records were skipped. Normalizing and validating the query value took the local fixture from 4/7 to 7/7 passing tests, including full traversal with no missing or duplicate records.

My small-fix checklist: • Reproduce the failure with safe inputs. • Check the returned data, not just the status code. • Keep the change bounded. • Save before/after evidence and document what remains untested.

Both examples use synthetic data and deliberately introduced failures. They are not client projects or production outcomes.

n8n case study: https://contra.com/p/7cvYA6N2-n8n-api-retry-repair-five-tested-cases

Pagination case study: https://contra.com/p/gg2qENZm-api-pagination-repair-from-47-to-77-tests

These are the kinds of contained failures my repair services cover. If you have one, share the failing step and expected result through Contra, without credentials or customer data.