How to find out the meaning, causes, and solutions for HTTP status codes

Classification and interpretation of HTTP status codes

• 1xx indicates processing continues, 2xx indicates success, and 3xx indicates redirect.
• 4xx indicates mostly request-side issues, 5xx indicates mostly server-side issues
• 401 and 403, 404 and 410, 429 and 503, etc. are similar but have different purposes.
• Also check related headers such as Retry-After, Location, WWW-Authenticate, and Cache-Control.

Steps to check the meaning of the code and what to do about it

1. Check the status code from your browser's developer tools, API client, or logs.
2. Search by code, English name, Japanese meaning, and open the details of the target code.
3. Check the main cause and confirmation items on the client/server side with the response body and headers.
4. As needed, compare similar codes side by side to identify the code to use in the API specification and differences in handling.
5. When retrying, check the wait time and maximum number of times to ensure that duplication of processing can be avoided.

Notes on fault investigation and API design

Even with the same status code, the cause differs depending on whether it was returned by the web server, CDN, authentication platform, or application. Check the response body, related headers, request ID, and server logs together.

If you mechanically resend non-idempotent processes such as POST, there is a risk of duplicate orders and payments being executed. Do not decide whether to retry based on the status code alone.

Specific example: Designing retries for 429 Too Many Requests

429 is returned when you send more requests than allowed in a short period of time. If you immediately retransmit at the same frequency, the limit will be extended, so check the Retry-After response and the rate limit specifications on the service side.

Automatic retries gradually increase the wait time and set a maximum number of attempts. If POST is included, check if there is an idempotent key or a means to query the processing results.

1. Search for 429 to see its meaning, retryability, and associated headers.
2. Check if the response has Retry-After using the developer tools.
3. Check the request limits and reset conditions in the API specifications.
4. Implement and test exponential backoff, maximum attempts, and duplication prevention.

If 429s persist, review call frequency, caching, batching, and contract limits rather than increasing the number of retries.

Frequently asked questions

Is all 4xx due to user operation error?

No. 4xx indicates that the request cannot be processed as is, but there are also implementation/operation-related causes such as authentication settings, URL generation, proxies, and API specification changes.

5xx, can I resend the same request immediately?

Not necessarily safe. Check the HTTP method's idempotency, whether the server may have already processed it, Retry-After, wait time, and maximum retry count.