La solicitud está bien formada, pero no supera la validación.
Cuándo usarlo
JSON válido con valores no válidos, como una fecha de fin anterior a la de inicio.
Causas habituales y soluciones
422 significa que el servidor entendió la sintaxis, pero el contenido no supera la validación: un campo obligatorio está vacío, un correo está mal formado, un rango de fechas está invertido o un ID referenciado no existe. FastAPI lo devuelve para cada error de validación de Pydantic, y Rails y Laravel lo usan cuando falla la validación de un modelo. Rails también devuelve 422 para un token CSRF no válido, lo que sorprende a más de uno.
Devuelve errores por campo en el cuerpo para que el cliente pueda mostrarlos junto a los campos correspondientes, idealmente con una estructura coherente como los problem details del RFC 9457. No reintentes un 422 sin cambiar los datos. Los equipos no se ponen de acuerdo entre 400 y 422; elige una regla, por ejemplo 400 para entradas que no se pueden analizar y 422 para entradas bien formadas pero no válidas, y aplícala en todas partes.
Error del cliente (4xx)
Los códigos 4xx son errores del cliente: la solicitud en sí es incorrecta, no está autorizada o apunta a algo que no existe. Repetir la misma solicitud no servirá de nada.
Cómo se ve
HTTP/1.1 422 Unprocessable ContentCómo enviarlo
| Node.js / Express | res.status(422).end() |
|---|---|
| Python / Flask | return '', 422 |
| nginx | return 422; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/