Best practice L2 · Context engineering informational

Tell Claude to Make API Failures Loud, Not Swallowed

What it is

An instruction to Claude that every external call must handle timeouts, non-2xx statuses, and malformed responses explicitly — surfacing typed errors — rather than the default happy-path client that assumes the network always works and JSON always parses.

fail loudRequestTimeout?Bad status?Typed error
Every network call has four outcomes, not one.

Why it works

Generated integration code optimises for the demo: it awaits the call, parses the body, and moves on. In production the call times out, the service returns a 503 with an HTML error page, or a field is null — and the swallowed failure shows up three layers away as an unrelated crash. Asking for loud, typed failures up front means problems surface at the boundary where they're diagnosable, with the context of which call failed and why.

When to use it

Any code that crosses a network boundary — third-party APIs, your own microservices, model APIs — and anything running unattended (jobs, webhooks, cron).

When not to use it

A quick local script you'll run once and watch. Don't build a resilience framework for a throwaway.

Prompt

Write the client for <API> so failures are impossible to ignore:
- explicit timeout on every request,
- check status; map 4xx and 5xx to distinct typed errors with the response body attached,
- guard JSON parsing; a non-JSON body is an error, not a crash,
- retries only for timeouts/5xx/429 with capped exponential backoff.
Do not catch-and-log-and-continue anywhere; either handle it meaningfully or let it propagate as a typed error.

Example

A webhook processor that used to silently drop events when the downstream API returned 429 now raises a RateLimited error, backs off, and retries — so the events are delivered instead of vanishing, and the logs say exactly what happened.

Advanced version

Ask Claude to add a circuit breaker around a flaky dependency: after N consecutive failures, fail fast for a cool-down window instead of hammering a service that's already down. Have it explain the thresholds so you can tune them.

Common mistakes

  • Accepting a bare try/catch that logs and continues — that's how errors get hidden.
  • Retrying non-idempotent writes and causing duplicates; only retry when it's safe.
  • No timeout, so one hung connection stalls the whole job indefinitely.

Related