O erro 422 (Unprocessable Entity) aparece quando o servidor entende perfeitamente o que você pediu, mas não consegue processar o pedido porque os dados enviados não passam nas regras de validação.
É uma distinção sutil e que confunde muita gente: diferente do erro 400, em que a requisição está malformada, no 422 a requisição está estruturalmente correta — o servidor leu tudo direitinho. O problema é o conteúdo: falta um campo obrigatório, um valor está no formato errado, ou algum dado contraria uma regra do sistema.
Neste guia você vai entender o que o código significa, por que ele acontece e como resolvê-lo — seja você quem está tentando enviar um formulário, quem está integrando uma API ou quem tem um site WordPress mostrando esse erro.
O erro 422 significa que o servidor entendeu a requisição e a sintaxe está correta, mas os dados enviados não passaram na validação — um campo obrigatório em branco, um formato inválido ou um valor que viola alguma regra. É um erro do cliente (série 4xx): repetir a mesma requisição vai dar o mesmo resultado. A solução é corrigir os dados. Se for um formulário, revise os campos; se for uma API, leia o corpo da resposta, que quase sempre diz exatamente qual campo falhou.
Conteúdo
O que é o erro HTTP 422
O código 422 Unprocessable Entity — renomeado para Unprocessable Content na especificação atual do HTTP (RFC 9110) — indica que o servidor entendeu o tipo de conteúdo da requisição, a sintaxe está correta, mas ele não conseguiu processar as instruções contidas ali dentro.
Uma analogia ajuda: imagine entregar um formulário de inscrição impecavelmente preenchido a mão, com letra legível e no formulário certo — mas você deixou o campo “CPF” em branco e escreveu uma data de nascimento no futuro. O atendente consegue ler tudo; ele só não pode aceitar, porque o conteúdo não faz sentido segundo as regras. Isso é o 422.
O código nasceu na extensão WebDAV do HTTP, mas hoje é amplamente usado por APIs REST modernas para comunicar falhas de validação — é provavelmente a resposta mais comum quando um dado enviado não passa nas regras do sistema.
Por estar na família 4xx, o 422 é classificado como um erro do cliente: a origem do problema está no que foi enviado, não numa falha do servidor. Isso tem uma consequência prática importante — tentar de novo sem mudar nada vai dar exatamente o mesmo erro. Só corrigir os dados resolve.
Erro 422 vs erro 400: a diferença que confunde todo mundo
Essa é a dúvida central de quem pesquisa o 422, e a distinção é mais simples do que parece:
- 400 Bad Request — a requisição está malformada. O servidor não conseguiu nem interpretar o que chegou: um JSON com uma chave faltando, um caractere inválido na URL, um cabeçalho quebrado. É um erro de sintaxe.
- 422 Unprocessable Entity — a requisição está bem formada. O servidor leu e entendeu tudo. O que falhou foi o significado dos dados: um e-mail sem “@”, um campo obrigatório vazio, um número enviado como texto. É um erro de semântica.
400 = o servidor não conseguiu ler o que você mandou. 422 = o servidor leu, entendeu, e recusou porque o conteúdo não passou na validação. Um JSON perfeitamente formatado pode dar 422; um JSON quebrado dá 400.
Por que o erro 422 acontece
As causas mais comuns, quase todas ligadas aos dados enviados:
- Campo obrigatório ausente. A API ou o formulário espera um dado que não foi enviado.
- Tipo de dado incorreto. Enviar
"29.99"(texto) onde se espera29.99(número), por exemplo. - Formato inválido. Um e-mail sem “@”, uma data fora do padrão esperado, um CPF com dígitos a menos.
- Violação de regra de negócio. Tentar cadastrar um e-mail que já existe, atualizar um registro inexistente, ou referenciar um ID que não existe.
- Cabeçalho
Content-Typeincompatível. O corpo é JSON, mas o cabeçalho diz outra coisa (ou vice-versa). - Valor fora dos limites. Um texto maior que o permitido, um número fora da faixa aceita.
Em sites WordPress, o 422 costuma aparecer em outro contexto: uma requisição da API REST do WordPress (usada pelo editor de blocos, por plugins e por integrações) que falha na validação, ou dados inconsistentes no banco.
Como resolver o erro 422 (para quem está acessando um site)
Se você recebeu o 422 ao enviar um formulário ou usar um site, o problema quase sempre está nos dados que você preencheu.
Revise cada campo do formulário. Procure campos obrigatórios em branco, e-mails digitados errado, datas fora do formato pedido, CPF ou telefone incompletos. Preste atenção às instruções e às dicas de formato que o próprio formulário mostra.
Verifique dados que precisam ser únicos. Se você está criando uma conta e o erro insiste, pode ser que o e-mail ou o usuário já existam no sistema.
Limpe o cache e os cookies do navegador. É menos comum, mas dados de sessão corrompidos podem atrapalhar o envio. Veja o passo a passo no nosso guia sobre como limpar o cache do navegador.
Tente em outro navegador ou numa janela anônima. Ajuda a descartar interferência de extensões ou de dados salvos.
Se depois de revisar tudo o erro continuar, o problema pode estar na validação do próprio site — regras mal configuradas ou com bug rejeitando dados legítimos. Nesse caso não há o que fazer do seu lado além de avisar o responsável pelo site.
Como resolver o erro 422 (para quem usa APIs)
Aqui está a boa notícia que muita gente ignora: o 422 quase sempre vem acompanhado da explicação. Diferente de outros erros, uma API bem construída devolve, no corpo da resposta, exatamente qual campo falhou e por quê.
Leia o corpo da resposta, não só o código. É o passo mais importante e o mais pulado. Registre (log) a resposta completa, não apenas o status 422 — o JSON de retorno geralmente traz algo como o campo problemático e a regra violada.
Confira os campos obrigatórios e os tipos. Compare seu payload com a documentação da API: todos os campos exigidos estão presentes? Os números estão como números, e não como texto entre aspas?
Verifique o cabeçalho Content-Type. Ele precisa corresponder ao formato do corpo que você está enviando (application/json para JSON, por exemplo).
Valide o JSON antes de enviar. Uma ferramenta de validação de JSON descarta a hipótese de estrutura quebrada — se o JSON estiver inválido, o retorno provavelmente seria 400, não 422, mas vale eliminar a dúvida.
Teste isolado, fora da aplicação. Refaça a requisição com uma ferramenta de API ou via linha de comando, com um payload mínimo, e vá acrescentando campos até o erro aparecer. Isso isola o campo culpado rapidamente.
Cheque conflitos e referências. Ao criar um registro, confirme que valores únicos (e-mail, ID) ainda não existem. Ao atualizar, confirme que o registro existe. E verifique se os IDs referenciados apontam para registros reais.
Diferente de erros temporários como o 503, o 422 é determinístico: enviar a mesma requisição de novo vai produzir exatamente o mesmo erro, quantas vezes você tentar. Se o seu código tem uma lógica de retry automático, ela não vai resolver um 422 — só vai repetir a falha. Corrija os dados primeiro.
Como resolver o erro 422 no WordPress
Se o 422 aparece no seu site WordPress — no editor, ao salvar um post, ou em alguma funcionalidade —, a causa costuma estar em uma requisição da API REST que falha na validação ou em dados inconsistentes.
Desative os plugins e teste um tema padrão. Um plugin em conflito é a causa mais frequente. Desative todos (renomeie a pasta plugins via FTP se não conseguir entrar no painel) e reative um a um até achar o culpado. Troque temporariamente para um tema padrão para descartar problema no tema.
Ative o modo de depuração. Assim você vê o erro real por trás do código. No wp-config.php, adicione:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Recarregue a página que dá erro e abra o arquivo debug.log, dentro da pasta wp-content. Ele vai apontar o arquivo e a linha do problema. Lembre de desativar o debug depois — não deixe ativo num site em produção.
Repare o banco de dados. Tabelas corrompidas (comum quando uma atualização é interrompida) causam erros variados, inclusive o 422. Adicione ao wp-config.php a linha define( 'WP_ALLOW_REPAIR', true ); e acesse seusite.com.br/wp-admin/maint/repair.php para rodar o reparo. Remova a linha depois. Alternativamente, use o phpMyAdmin pelo painel da sua hospedagem: selecione as tabelas do banco de dados e use a opção Reparar tabela.
Verifique se algum código customizado quebrou. Se o erro começou depois de você editar um arquivo (functions.php, um plugin próprio), reverta a alteração — um erro de lógica ali pode derrubar a validação de uma requisição.
Erro 422 vs erros parecidos
| Código | O que significa | Quando aparece |
|---|---|---|
| 422 Unprocessable Entity | Sintaxe correta, conteúdo inválido | Campo obrigatório vazio, formato errado, regra violada |
| 400 Bad Request | Requisição malformada | JSON quebrado, URL inválida, cabeçalho corrompido |
| 409 Conflict | Conflito com o estado atual do recurso | Edição simultânea, versão desatualizada |
| 401 Unauthorized | Falta autenticação válida | Token ausente, inválido ou expirado |
| 500 Internal Server Error | Falha do lado do servidor | Bug no código do servidor — não é culpa dos seus dados |
Uma comparação que vale fixar: o 500 é o cozinheiro que queimou o prato por culpa do forno; o 422 é o cozinheiro que se recusa a cozinhar porque os ingredientes que você trouxe estão incompletos — mesmo tendo chegado na embalagem certa.
Para ver o panorama completo dos códigos de resposta, veja nosso guia sobre status HTTP e os códigos de resposta.
Perguntas frequentes
O que significa o erro 422?
Significa “Unprocessable Entity” (entidade não processável): o servidor entendeu a requisição e a sintaxe está correta, mas não conseguiu processá-la porque os dados enviados não passaram na validação. Pode ser um campo obrigatório em branco, um formato inválido ou um valor que viola uma regra do sistema.
Qual a diferença entre o erro 400 e o erro 422?
O 400 (Bad Request) indica que a requisição está malformada — o servidor não conseguiu nem interpretar o que chegou, como um JSON quebrado. O 422 indica que a requisição está bem formada e foi entendida, mas o conteúdo não passou na validação. Em resumo: 400 é erro de sintaxe, 422 é erro de semântica.
O erro 422 é problema meu ou do servidor?
O 422 pertence à família 4xx, os erros do cliente, então a causa está nos dados enviados na requisição. A exceção é quando a validação do próprio site está mal configurada e rejeita dados legítimos — aí só o responsável pelo site pode corrigir.
Como resolver o erro 422 rapidamente?
Se for um formulário, revise cada campo em busca de obrigatórios em branco, formatos errados ou valores duplicados. Se for uma API, leia o corpo da resposta: ele quase sempre indica exatamente qual campo falhou. Confira também os campos obrigatórios, os tipos de dados e o cabeçalho Content-Type.
Adianta tentar de novo quando dá erro 422?
Não. O 422 é determinístico: a mesma requisição vai produzir o mesmo erro sempre. Diferente de erros temporários de servidor, aqui não existe “tentar mais tarde” — é preciso corrigir os dados antes de reenviar.
Por que meu site WordPress mostra erro 422?
Em geral é um conflito de plugin, um erro em código customizado ou uma tabela corrompida no banco de dados afetando as requisições da API REST. Desative os plugins para achar o conflito, ative o modo de depuração para ver o erro real no debug.log e, se necessário, repare o banco de dados pelo phpMyAdmin.
O erro 422 prejudica o SEO?
Diretamente, não — o 422 costuma aparecer em requisições de formulários e APIs, não nas páginas que o Google indexa. Mas se ele impede funcionalidades importantes do site, como cadastros ou compras, o prejuízo é para a experiência e a conversão, o que acaba refletindo nos resultados.
Erros como o 422 costumam vir de conflitos de plugin, banco de dados ou código. Com a hospedagem da Homehost, você tem phpMyAdmin no painel, logs acessíveis e um suporte que entende de servidor para diagnosticar rápido.
Conhecer a hospedagem HomehostConclusão
O erro 422 é o mais “educado” dos erros HTTP: o servidor entendeu tudo o que você pediu e está apenas dizendo que os dados não passam nas regras. Por isso a solução nunca é insistir — é corrigir. Para quem preenche um formulário, revisar os campos resolve a grande maioria dos casos. Para quem integra uma API, o segredo está em ler o corpo da resposta, que quase sempre aponta o campo exato que falhou. E para quem tem um site WordPress, o caminho passa por isolar plugins, ativar o debug e, se preciso, reparar o banco. Entendida a diferença entre “não consegui ler” (400) e “li, mas não posso aceitar” (422), o erro deixa de ser um mistério.
