API Error Decoder: Make Sense of a Failed Request
An API failure usually gives you two things: an HTTP status code and a response body — and both carry information that's easy to skim past when you're debugging under pressure. This tool pairs a reference for the most common status codes (what they mean, why they typically happen) with pattern recognition for a handful of widely-used error response shapes.
Shape detection checks your parsed JSON against a few well-known field patterns — an unmatched shape just means this tool doesn't recognize that particular API's convention.
Status Codes Tell You the Category, Not the Cause
A 422 tells you the request was understood but failed validation — it doesn't tell you which field or rule failed. That's exactly what the error body is for, which is why this tool pairs the status-code reference with body-shape parsing rather than treating the code alone as the full picture.
Why Recognizing the Error Shape Matters
Stripe's `error.type` and `error.code` fields, GitHub's `documentation_url` pointing to relevant docs, OAuth2's `error`/`error_description` pair, and GraphQL's `errors` array each carry structured information beyond a plain message string — once you recognize the pattern, you know exactly which field to read for the specific reason a request failed.
Practical Examples
Debugging a Stripe Rate Limit
A 429 response with a Stripe-style error object.
- 1.Status: 429 → 'Too Many Requests' explained
- 2.Paste the error body
- 3.Detected shape pulls out type: rate_limit_error and the message
Status Codes Covered
- 400, 401, 403, 404, 405, 408, 409, 410
- 413, 415, 422, 429
- 500, 502, 503, 504
Error Shapes Recognized
- Stripe: { error: { type, code, message } }
- GitHub: { message, documentation_url }
- OAuth2: { error, error_description }
- GraphQL: { errors: [{ message, ... }] }
Frequently Asked Questions
What status codes does the reference cover?
The most common REST API error codes: 400, 401, 403, 404, 405, 408, 409, 410, 413, 415, 422, 429, 500, 502, 503, and 504 — each with its meaning and typical real-world causes.
How does error body shape detection work?
The tool checks your parsed JSON error body against a few well-known conventions: Stripe's `{ error: { type, code, message } }`, GitHub's `{ message, documentation_url }`, OAuth2's `{ error, error_description }`, and GraphQL's `{ errors: [{ message, ... }] }` — if your body matches one of these shapes, the relevant fields are pulled out and labeled.
Why isn't my error body's shape recognized?
Every API designs its own error response format — the tool only recognizes a handful of especially common conventions. An unrecognized shape isn't a problem with your response; it just means this tool doesn't have a specific pattern for it yet.
What's the difference between 401 and 403?
401 Unauthorized means the request lacks valid credentials at all (or they're invalid/expired) — the server doesn't know who you are. 403 Forbidden means the server does know who you are, but you don't have permission to do what you're trying to do.
What's the difference between 400 and 422?
400 Bad Request typically means the request itself is malformed (invalid JSON, wrong data type). 422 Unprocessable Entity means the request is well-formed and understood, but fails a business-logic or validation rule (e.g. an email that's syntactically valid but already taken).
Is my error body sent anywhere?
No, all parsing and pattern matching happens locally in your browser.