Client code handles the 200 case fine. The 401 that needs a token refresh, the 422 with field-level errors, the 429 with a Retry-After — those are where it breaks. Pick a status here and get a complete, correctly shaped response for it.
What you can control
- Error bodies carry a type, a message, a code and a request ID, which is the shape most real APIs use.
- A 422 includes field-level validation details, so you can test inline error rendering.
- Response headers include rate-limit and request-ID fields that clients commonly read.
- The pagination envelope wraps list responses with page metadata and navigation links.
What this is not
This produces static response text for use in a mock server or a fixture file. It does not stand up a live endpoint.
Questions
Can I point my app at this as a live API?
No. It generates response text to paste into a mock server such as MSW, Mirage, WireMock or a Postman example.
Why does the error body have a request ID?
Because that is what makes a production error report actionable. Including one in your fixtures means your error display has somewhere to put it.
What does the 422 detail array contain?
A field name, the rule that failed, and a human-readable message — the minimum a form needs to show an error next to the right input.