É 422 Unprocessable Entity ou Unprocessable Content?

Os dois. A RFC 4918 (WebDAV) chamava de Unprocessable Entity; a RFC 9110 trouxe o código para o HTTP principal em 2022 e mudou o nome para Unprocessable Content. Frameworks e bibliotecas ainda usam qualquer um dos nomes, e o número continua o mesmo.

Devo usar 400 ou 422 para erros de validação?

Use 400 quando o pedido não pode ser lido (JSON malformado, codificação errada) e 422 quando ele é lido mas os valores não passam nas suas regras. Muitas APIs públicas usam 400 para tudo; o importante é ser consistente e devolver os erros por campo.

Por que o FastAPI retorna erro 422?

O FastAPI valida cada pedido contra os parâmetros declarados e os modelos Pydantic, e qualquer divergência vira 422 automaticamente. Os suspeitos de sempre são campo obrigatório ausente, tipo errado ou form data enviado para um endpoint que espera JSON.

Como resolver o erro 422 num formulário?

Leia a mensagem ao lado de cada campo e corrija o valor indicado. Se a página não mostra detalhes, abra as ferramentas de desenvolvedor, encontre a requisição com falha na aba Rede e leia o corpo da resposta, que costuma listar os campos inválidos.

Código de status HTTP · Erros do cliente (4xx)

Erro 422 Unprocessable Content

O erro 422 Unprocessable Content (antes chamado Unprocessable Entity) significa que o servidor entendeu o formato do corpo e conseguiu lê-lo, mas os dados não podem ser processados. A causa mais comum é falha de validação: um campo obrigatório faltando, um valor com tipo errado ou dois campos que se contradizem.

Dados sobre este código de status
Classe	4xx, Erros do cliente
Também chamado de	Unprocessable Entity
Definido em	RFC 9110 §15.5.21
Pode ir para o cache por padrão	Só com Cache-Control ou Expires explícitos
Pode repetir o pedido	Só depois de corrigir o corpo do pedido; o mesmo payload falha na mesma validação
Cabeçalhos relevantes	`Content-Type`: application/problem+json (RFC 9457) funciona bem para listar os erros por campo

O que significa o 422

A RFC 9110, seção 15.5.21, posiciona o 422 entre dois outros códigos: o tipo de conteúdo é aceito (senão seria 415) e a sintaxe está certa (senão seria 400), mas as instruções ali dentro não podem ser executadas. O código nasceu no WebDAV (RFC 4918) como "Unprocessable Entity" e entrou no HTTP principal em 2022 com o nome "Unprocessable Content". Os dois nomes são o mesmo número.

Na prática, o 422 virou a resposta padrão para erro de validação em formulários e APIs. O FastAPI devolve 422 sozinho quando o pedido não bate com o modelo Pydantic, com um array detail apontando cada campo com problema. O Laravel usa 422 quando um FormRequest falha, e os scaffolds do Rails respondem :unprocessable_entity quando o save não passa.

O valor está no corpo da resposta. Um 422 sem detalhes obriga o cliente a adivinhar qual campo estava errado; uma lista com o caminho do campo e a mensagem permite que o formulário destaque o input certo.

Causas comuns

Se você está visitando o site

O formulário foi enviado com um campo que o site recusa: email inválido, data no passado, senha menor que o mínimo.
Uma extensão do navegador ou o preenchimento automático colocou um valor inesperado num campo oculto.

Se você administra o servidor

O cliente manda um campo com nome ou tipo diferente do esperado pelo schema, como "userId" no lugar de "user_id", ou o número 42 como string "42" para um validador estrito.
No FastAPI, um parâmetro declarado sem valor padrão vira obrigatório, então um query param ou campo do corpo ausente gera 422 com "field required".
Corpo enviado como form data para um endpoint que espera JSON (ou o contrário) aparece como 422 no FastAPI, porque todos os campos parecem estar faltando.
Regras de negócio sobre dados válidos no formato: data final antes da inicial, quantidade acima do estoque, cupom vencido.

Como resolver

Se você está visitando o site

Leia a mensagem ao lado de cada campo; normalmente o formulário diz qual valor foi recusado.
Desative o preenchimento automático ou as extensões naquela página e digite os valores à mão.

Se você administra o servidor

Registre ou imprima o corpo da resposta: o FastAPI coloca cada problema em detail[].loc e detail[].msg, que apontam direto para o campo.
Confira se o Content-Type enviado pelo cliente é o que o endpoint lê (application/json ou multipart/form-data).
Compare o payload com o schema ou o documento OpenAPI; atenção a camelCase contra snake_case e a números enviados como texto.
Use 422 só para problemas de significado. Se o JSON nem pode ser lido, responda 400, para o cliente distinguir corpo quebrado de valores inválidos.

Como enviar um 422

Express (Node.js)

app.post('/bookings', (req, res) => {
  res.status(422).json({ error: 'Validation failed', fields: { endDate: 'Must be after startDate' } });
});

Next.js App Router (route handler)

// app/bookings/route.ts
export async function POST() {
  return Response.json(
    { error: 'Validation failed', fields: { endDate: 'Must be after startDate' } },
    { status: 422 }
  );
}

Go net/http

mux.HandleFunc("POST /bookings", func(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusUnprocessableEntity) // 422
	w.Write([]byte(`{"error":"Validation failed","fields":{"endDate":"Must be after startDate"}}`))
})

Python FastAPI

from datetime import date
from fastapi import FastAPI
from pydantic import BaseModel, model_validator

app = FastAPI()

class Booking(BaseModel):
    start_date: date
    end_date: date

    @model_validator(mode="after")
    def check_dates(self):
        if self.end_date <= self.start_date:
            raise ValueError("end_date must be after start_date")
        return self

# FastAPI answers 422 on its own when the body fails validation
@app.post("/bookings")
def create_booking(booking: Booking):
    return booking

Costuma ser confundido com

422 vs 400: O 400 serve para um pedido que o servidor nem consegue ler, como JSON quebrado; o 422 serve para um corpo que é lido sem erro mas tem valores inválidos.
422 vs 409: O 409 indica dados válidos que batem de frente com o estado atual, como um nome de usuário já em uso; o 422 indica que os próprios dados são inválidos.
422 vs 415: O 415 recusa o formato (por exemplo XML para uma API que só aceita JSON); o 422 aceita o formato e recusa o conteúdo.

Perguntas frequentes

É 422 Unprocessable Entity ou Unprocessable Content?: Os dois. A RFC 4918 (WebDAV) chamava de Unprocessable Entity; a RFC 9110 trouxe o código para o HTTP principal em 2022 e mudou o nome para Unprocessable Content. Frameworks e bibliotecas ainda usam qualquer um dos nomes, e o número continua o mesmo.
Devo usar 400 ou 422 para erros de validação?: Use 400 quando o pedido não pode ser lido (JSON malformado, codificação errada) e 422 quando ele é lido mas os valores não passam nas suas regras. Muitas APIs públicas usam 400 para tudo; o importante é ser consistente e devolver os erros por campo.
Por que o FastAPI retorna erro 422?: O FastAPI valida cada pedido contra os parâmetros declarados e os modelos Pydantic, e qualquer divergência vira 422 automaticamente. Os suspeitos de sempre são campo obrigatório ausente, tipo errado ou form data enviado para um endpoint que espera JSON.
Como resolver o erro 422 num formulário?: Leia a mensagem ao lado de cada campo e corrija o valor indicado. Se a página não mostra detalhes, abra as ferramentas de desenvolvedor, encontre a requisição com falha na aba Rede e leia o corpo da resposta, que costuma listar os campos inválidos.

Revisado em 27 de setembro de 2026 por Arielton Oberek.