HTTP 422 field note
API 422 validation errors: locate the field path that failed
Interpret 422 Unprocessable Content responses, nested validation paths, enum failures, business rules, and framework-specific error arrays.
A 422 usually means the server understood the content type and syntax but rejected the instructions. The fastest route is to normalize the provider’s field-path format—JSON Pointer, dotted keys, loc arrays, or parameter names—then compare the rejected value with both schema and business constraints.
Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.
Diagnostic procedure
Work from evidence to recovery.
- 01
Normalize the error path
Convert forms such as body.items.0.price, /items/0/price, and [body, items, 0, price] into one readable path.
- 02
Inspect value and constraint
Check type, format, length, range, enum, nullability, and cross-field business rules at that path.
- 03
Preserve all errors
Some validators return multiple issues. Fixing only the first can hide a second invalid branch or array item.
{"detail":[{"loc":["body","items",0,"price"],"msg":"greater than 0"}]}Path: $.items[0].price Constraint: exclusiveMinimum 0 Received: 0
Evidence
HTTP 429: A rate, quota, concurrency, or resource lock limit blocked the request.
Retry-After is present; it should take precedence over a guessed delay.
The reported request window has no remaining capacity.
Next checks
01Parse Retry-After as either delta-seconds or an HTTP date before scheduling the next attempt.
No account · no upload · no endpoint calledOpen the full incident decoder and operating notes →
FAQ
Before you ship
Does APITC send this evidence to an API?
No. The matching and calculations in the linked workbench run in the active browser tab.
Should every 422 response be retried?
No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.
Protocol behavior checked against the MDN — 422 Unprocessable Content. Recheck your pinned provider/API version before production deployment.