HTTP status codes / 4xx — Client errors
Syntax is fine; the data is semantically invalid.
The body parsed correctly but fails validation rules: missing required field, invalid email format, business-rule violations. The de-facto standard for validation errors in REST APIs (Rails popularized it).
curl -i -X POST -H "Content-Type: application/json" -d '{"email":"not-an-email"}' https://your-api.example/users Same request, no terminal: paste this into the cURL converter for native code, or straight into ReqPad on your phone.
Read the response body — well-built APIs return a field-by-field error map. Compare it with the API schema, not with what your client "should" be sending.
Server-side note: Well-built APIs return a field-by-field error map in the body — read it before changing anything blindly.
The fastest way to pin down a 422 is to reproduce the exact request and inspect what actually went over the wire — status, headers, timing and body, without your app code in the way. That is what an API client is for; ReqPad does it from your phone, with every request saved to history.
400 Bad Request · 401 Unauthorized · 402 Payment Required · 403 Forbidden · 404 Not Found · 405 Method Not Allowed — or the full reference.
Build the request, send it, read status + headers + timing — on your iPhone. Free to start.