What does a good API error response look like?
A good API error uses the right status code and a consistent, machine-readable body. RFC 9457 (Problem Details) standardises that body: a type URI, a short title, the status, a human-readable detail and an instance identifier, in application/problem+json. It tells the caller what went wrong and how to fix it without exposing stack traces, SQL or internal paths.
How to use AI API Response → Potential Issues
- Paste the response — the status line, headers and body, or just the JSON.
- Optionally paste the expected contract (a schema or a description) and the request it answered.
- Pick the output language and press Analyze.
- Go through the issues from Critical down; each points at a JSON path and quotes the value that shows the problem. Download as CSV, Markdown or JSON.
AI API Response → Potential Issues features
- Spots inconsistent types, missing fields, wrong status semantics, leaked data, bad date formats, null handling, naming and pagination smells
- Every issue carries a JSON path and quoted evidence
- Optional expected contract to compare against
- Health score plus "looks good" list
AI API Response → Potential Issues example
Response review
Input:
{"data":[{"id":1,"passwordHash":"…"},{"id":"2","createdAt":"02/01/2026"}]}Output:
ISS-1 data-exposure (Critical) $.data[0].passwordHash
ISS-2 inconsistent-type (High) $.data[*].id — number vs string
ISS-3 bad-date-format (Medium) $.data[1].createdAtFrequently asked questions about AI API Response → Potential Issues
Should I include headers?
Yes when you can — status and headers let the AI check status semantics, content types and caching in addition to the body.
What happens when I add the expected contract?
The response is compared with it, and every deviation — a missing field, a different type, an unexpected status — is reported as an issue.
How are severities assigned?
Critical is data exposure or data corruption, High is something that will break clients, Medium is a contract or quality problem, and Low is cosmetic.
Technical notes
Each issue has an ID, a kind (inconsistent type, missing field, wrong status, data exposure, bad date format, null handling, naming, duplicate, encoding, pagination, error format, performance or other), a severity, the JSON path, header or "status" it concerns, the evidence value and a suggested fix. The report adds a 0–100 health score and a "looks good" list; an issue that cannot be pointed at in the response is not reported.
References
- RFC 9457: Problem Details for HTTP APIsThe application/problem+json error format (type, title, status, detail, instance) for machine-readable API errors.
- OWASP Cheat Sheet Series: Error HandlingError responses that help the caller without leaking stack traces, versions or internal paths.
- RFC 9110: HTTP SemanticsThe meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.