Design for the Error Responses First

An integration pattern where you have Claude map out and handle the failure responses of an API — timeouts, rate limits, 5xx, partial or malformed bodies — before wiring up the happy path, so resilience is designed in rather than bolted on after an incident.

The happy path is the easy 20% of an integration; the failures are the 80% that decides whether it survives contact with production. Deciding up front how each failure is handled — retry, back off, surface, degrade — prevents the default of an unhandled rejection taking down the request. Claude knows the standard failure taxonomy for HTTP APIs and can turn 'what could go wrong' into concrete handling.

Any integration in a path that matters — payments, auth, anything user-facing or money-touching. The higher the cost of a silent failure, the more this pays off.

A throwaway script or an internal tool where a crash is an acceptable outcome and you'll just rerun it. Don't build retry-with-backoff for a one-shot report.

I'm integrating <API> for <purpose>. Before the happy path, map the failure modes: timeout, connection error, 429 rate limit, 4xx client errors, 5xx server errors, and malformed/partial responses. For each, decide the behaviour — retry with backoff, fail fast, surface to the user, or degrade — and justify it for this use case. Then implement the client with that error handling, and the happy path last.

For a payments call, Claude's failure map says: retry 5xx and timeouts with jittered backoff, never retry a 4xx (the charge may have succeeded), respect the 429 Retry-After header, and treat a malformed body as a hard failure needing manual reconciliation. The happy path is ten lines; the resilience is the part that keeps you out of a double-charge incident.

Ask Claude to make retries idempotent — using an idempotency key so a retried request can't double-execute — and to distinguish 'definitely failed' from 'unknown outcome', which need different handling. The unknown-outcome case is the one that quietly causes duplicate charges and double sends.

• Blindly retrying non-idempotent requests, turning one timeout into two charges.
• Collapsing every failure into a generic catch that logs and moves on, hiding the ones that need action.
• Building the happy path first and promising to 'add error handling later' — later is the incident.