A requisição está bem-formada, mas não passa na validação.
Quando usar
JSON válido com valores inválidos, como uma data de término anterior à data de início.
Causas comuns e soluções
O 422 significa que o servidor entendeu a sintaxe, mas o conteúdo não passa na validação: um campo obrigatório está vazio, um e-mail está malformado, um intervalo de datas está invertido ou um ID referenciado não existe. O FastAPI o retorna para todo erro de validação do Pydantic, e o Rails e o Laravel o usam para falhas de validação de modelo. O Rails também retorna 422 para um token CSRF inválido, o que surpreende muita gente.
Retorne erros por campo no corpo para que o cliente possa mostrá-los ao lado dos campos certos, de preferência em um formato consistente, como os problem details da RFC 9457. Não repita um 422 sem mudar os dados. As equipes divergem sobre 400 versus 422; escolha uma regra, por exemplo 400 para entrada que não dá para interpretar e 422 para entrada bem-formada, mas inválida, e aplique-a em todo lugar.
Erro do cliente (4xx)
Os códigos 4xx são erros do cliente: a própria requisição está errada, não está autorizada ou aponta para algo que não existe. Repetir a mesma requisição não vai adiantar.
Como fica
HTTP/1.1 422 Unprocessable ContentComo enviar
| Node.js / Express | res.status(422).end() |
|---|---|
| Python / Flask | return '', 422 |
| nginx | return 422; |
Como verificar
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/