According to the HTTP RFC:

> HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.

RFC2616 doesn’t go into detail about how new status codes get registered, but [RFC2817 does](http://tools.ietf.org/html/rfc2817#section-7.1) (and apparently updates RFC2616). That points to an [IANA registry](http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) that includes `422`.

My preference for `422` is because it’s the most specific HTTP code that applies, and still leaves `400` available for syntactically invalid requests (for example, to [reject invalid character encoding](https://github.com/alext/invalid_utf8_rejector)). Clients that don’t understand `422` are required by the spec to treat it as a generic `4xx` response anyway.

Either way, I’m very much aware that this is at least the third time I’ve had this discussion with someone about designing an API. We should agree on one convention, **write it down** somewhere, and use it throughout our stack.