What is problem+json and why use it?

It is the error format standardised in RFC 9457: a small set of agreed fields so clients and logs can read errors from any API the same way, instead of every service inventing its own error envelope.

Why does status appear in both the body and the response?

The body's status mirrors the HTTP status so that a logged or forwarded error document stays meaningful once it is separated from the response. RFC 9457 requires the two to agree, and a mismatch is a bug worth asserting on.

Is the errors array part of the standard?

No. RFC 9457 allows extension members, and errors is one — the field-level detail that GitHub- and Stripe-style APIs commonly add. Your client should treat the standard members as guaranteed and extensions as optional.

Mock an RFC 9457 problem+json error

A GET mock that returns a 422 application/problem+json validation error shaped per RFC 9457.

RFC 9457 defines application/problem+json, a standard shape for HTTP error bodies with type, title, status and detail. This template returns a 422 problem document with a field-level errors extension, so you can build and test error handling against the format rather than against whatever ad-hoc JSON your backend happens to emit today.

Stands in for a third-party API endpoint.

Response payload

{"type":"https://quickmock.dev/problems/validation-error","title":"Your request parameters didn't validate","status":422,"detail":"The 'email' field must be a valid email address.","instance":"{{mock.url}}/requests/38f0","errors":[{"field":"email","message":"must be a valid email address"}]}

Fields worth knowing

Field	What it means
type	A URI identifying the problem type — it's a documentation address, not necessarily a working link.
title	A short, human-readable summary of the problem.
status	Mirrors the HTTP response status, kept in the body for clients that log it separately.
detail	A specific explanation for this occurrence; edit it to match the failure you're testing.
errors	A non-standard extension array with field-level errors, the kind GitHub- or Stripe-style APIs often add.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 422,
  "content_type": "application/problem+json",
  "response_body": "{\"type\":\"https://quickmock.dev/problems/validation-error\",\"title\":\"Your request parameters didn't validate\",\"status\":422,\"detail\":\"The 'email' field must be a valid email address.\",\"instance\":\"{{mock.url}}/requests/38f0\",\"errors\":[{\"field\":\"email\",\"message\":\"must be a valid email address\"}]}"
}'

Call it

curl https://quickmock.dev/m/<slug>

What you get

GET /m/<slug> -> 422 application/problem+json
an RFC 9457 problem document with a custom errors[] extension

How this differs from the real thing

This is one fixed validation error — status, detail, and the errors[] extension are all hardcoded, so edit the response body to reproduce the exact failure your client needs to handle instead of a generic 422.

Sources

FAQ

What is problem+json and why use it?: It is the error format standardised in RFC 9457: a small set of agreed fields so clients and logs can read errors from any API the same way, instead of every service inventing its own error envelope.
Why does status appear in both the body and the response?: The body's status mirrors the HTTP status so that a logged or forwarded error document stays meaningful once it is separated from the response. RFC 9457 requires the two to agree, and a mismatch is a bug worth asserting on.
Is the errors array part of the standard?: No. RFC 9457 allows extension members, and errors is one — the field-level detail that GitHub- and Stripe-style APIs commonly add. Your client should treat the standard members as guaranteed and extensions as optional.

Ready to use it?

Open it in the mock builder to tweak first

Pairs well with this guide: Mock a specific error response

Related templates

← All templates

Last updated: 2026-10-17