API reference
HTTP Status Lookup
Enter a status code or API situation:
This is the Unprocessable Content.
The request shape is valid, but the values fail validation or domain rules.
Use 422 for form validation, invoice totals, date ranges, and other domain-specific checks.
Return field-level errors where possible.
Working example
{
"error": "Validation failed",
"fields": { "email": "Invalid email" }
}Before committing an API response
- Use one predictable error envelope across routes.
- Return field-level errors for validation and safe public messages for server failures.
- Write down what the client should do after receiving this status.
Common mistakes
- Returning 200 with an error field for failed operations.
- Using 401 for users who are logged in but do not have permission.
- Leaking stack traces, SQL errors, internal IDs, or secrets in response bodies.
Direct answer
A concise HTTP status reference for API design, form validation, auth errors, conflicts, rate limits, and production-safe failures.
What this tool solves
Choose a response status that tells clients what happened and what they should do next.
Input and output
- Input: A status code or scenario such as validation, conflict, auth, or rate limiting
- Output: Meaning, API example, client behavior, and production caveat
- Privacy: Runs entirely in the browser
Best used for
- API design reviews before frontend and backend teams agree on error handling.
- Form validation, auth failures, permission checks, duplicate records, and rate limits.
- Writing safer error responses that help clients recover without leaking internals.
Do not use it blindly when
- Your framework or API gateway has a strict response contract you must follow.
- A legal, payment, or tax workflow requires domain-specific error semantics.
Pre-publish checklist
- Return a consistent JSON error shape for all non-2xx responses.
- Separate authentication failures from permission failures.
- Include field-level errors for validation and Retry-After for rate limits when possible.
Example searches
Useful starting inputs include: 422 validation, 409 duplicate slug, 401 missing token, 429 rate limit.
Production use
Use the result as a decision aid, then verify it in the real product context. Browser support, API contracts, validation behavior, timezones, accessibility, monitoring, and handoff documentation can still change the right implementation.