Problem Details Example: A Validation Error on Three Fields

An order with a bad email, a negative quantity and a missing address gets one response naming all three.

A validation error for several fields should report every invalid field in one response, each with where it is and what is wrong, so the client fixes them all at once. Here is an order with three faults, and the problem details response that answers it. Both are illustrative.

json

{
  "email": "ana@",
  "items": [{"sku": "pen-blue", "quantity": -1}]
}

The request body to POST /orders: a bad email, a negative quantity and no address

json

{
  "type": "https://api.example.com/problems/validation",
  "title": "The request has invalid fields",
  "status": 422,
  "errors": [
    {"pointer": "#/email", "detail": "must be a valid email address"},
    {"pointer": "#/items/0/quantity", "detail": "must be at least 1"},
    {"pointer": "#/address", "detail": "is required"}
  ]
}

The 422 response, naming all three faults in an errors extension

One response, every fault. A server that stops at the first error makes the client fix the email, send again, learn about the quantity, send again, and only then hear about the address. Three round trips, and a user who sees a new red field each time.

A pointer per fault. Each entry locates the field with a JSON Pointer, a standard path into a JSON document: #/items/0/quantity is the quantity of the first item. A form can put each message beside its field without parsing text. The errors member and its pointer follow the example RFC 9457 itself gives.

One type for the whole response. The type says this is a validation failure; the entries say where. A client branches once, on the type, then loops over the list.

Why 422. The body was valid JSON, so the server read it; the values broke rules. A body that was not valid JSON could not be checked field by field, and gets a 400 with no list.

← → move through sections and cards