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

When this guide is useful

This is for users who want to find out a list of HTTP status codes, the meaning of 404 and 500 errors, the difference between 401 and 403, what to do with 429 and 503, and whether redirects, retries, and caching are possible.

• Isolate the cause of API requests failing with 401, 403, or 404
• Consider how to retry clients that receive a 429 or 503.
• Compare the differences between 301, 302, 307, and 308 and design a redirect
• Additional information for this feature.

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. Additional information: API
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

Additional information: Web CDN ID

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?

Additional information: HTTP Retry-After