HTTP errors and retries: 401, 403, 429 and 5xx

Separate transport and HTTP errors

An HTTP status means an HTTP response was received. DNS, TLS and connectivity failures happen before that and may produce no status at all.

JavaScript fetch normally resolves for 4xx and 5xx responses. Check response.ok or status; a rejected promise alone is not an HTTP error classifier.

Read authentication failures in context

401 concerns authentication and commonly carries a challenge. 403 means the server refuses the request; retrying the same credentials is not an automatic fix.

Inspect the API error body and authentication scheme. A service may intentionally hide resource existence with 404, so status alone cannot reveal every policy.

Respect throttling signals

429 indicates too many requests under the service’s policy. Retry-After, when supplied, can describe a delay or HTTP date.

Use a bounded retry policy with backoff and jitter for appropriate failures. Stop after the attempt or time budget instead of creating an infinite retry loop.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Protect side effects

A timeout or 5xx can occur after the server performed the operation. Repeating a payment-like POST may duplicate the effect.

Use the API’s documented idempotency mechanism and request identifiers. A generic status lookup explains meaning but cannot decide whether your business operation is safe to retry.