100
Continue
O servidor recebeu os cabeçalhos e o cliente pode continuar a enviar o corpo. Evita enviar um payload grande se o servidor puder rejeitar o pedido.
Todas as utilidades
Referência
Códigos de estado HTTP
Referência pesquisável de códigos de resposta HTTP comuns.
1xx Informativos
101
Switching Protocols
O servidor concorda em mudar de protocolo (por exemplo de HTTP para WebSocket) conforme solicitado no cabeçalho Upgrade.
102
Processing
O servidor recebeu e está a processar o pedido, mas ainda não há corpo de resposta. Usado em operações de longa duração.
2xx Sucesso
200
OK
O pedido foi bem-sucedido. O corpo de resposta contém normalmente o recurso solicitado ou o resultado da operação.
201
Created
O pedido foi bem-sucedido e foi criado um novo recurso. Frequentemente após POST com cabeçalho Location a apontar para o novo recurso.
202
Accepted
O pedido foi aceite para processamento mas ainda não está concluído. Comum em tarefas assíncronas e em segundo plano.
204
No Content
O pedido foi bem-sucedido mas não há conteúdo a devolver. Típico de DELETE ou PUT bem-sucedidos com corpo vazio.
3xx Redireccionamento
301
Moved Permanently
O recurso foi movido permanentemente para um novo URL. Clientes e motores de busca devem actualizar favoritos e ligações.
302
Found
O recurso está temporariamente disponível noutro URL. Pedidos futuros podem ainda usar o URL original.
303
See Other
Após um POST, o cliente deve obter o resultado com GET no URL indicado no cabeçalho Location.
304
Not Modified
A versão em cache ainda é válida. O servidor não devolve corpo; o cliente deve usar a cache local.
307
Temporary Redirect
Redireccionamento temporário que preserva o método HTTP original. Ao contrário do tratamento antigo do 302, POST mantém-se POST após redireccionamento.
308
Permanent Redirect
Redireccionamento permanente que preserva o método HTTP original. O cliente deve usar o novo URL em pedidos futuros.
4xx Erro do cliente
400
Bad Request
O servidor não consegue processar o pedido devido a sintaxe inválida, campos em falta ou JSON mal formado. Corrija o pedido e tente novamente.
401
Unauthorized
A autenticação é necessária ou falhou. O cliente deve fornecer credenciais válidas, muitas vezes via cabeçalho Authorization ou início de sessão.
403
Forbidden
O servidor compreendeu o pedido mas recusa autorizá-lo. O utilizador pode estar autenticado mas sem permissão.
404
Not Found
O URL ou recurso solicitado não existe. Verifique o caminho, route ou ID — ou o item pode ter sido removido.
405
Method Not Allowed
O método HTTP não é permitido neste endpoint. Por exemplo, enviar POST onde apenas GET é suportado.
408
Request Timeout
O servidor expirou à espera do pedido completo. Frequentemente por uploads lentos ou ligações inactivas.
409
Conflict
O pedido entra em conflito com o estado actual do recurso. Comum ao criar duplicados ou violar restrições de versão.
410
Gone
O recurso existiu mas foi removido permanentemente e não voltará a estar disponível. Mais forte que 404 para conteúdo eliminado.
413
Payload Too Large
O corpo do pedido é maior do que o servidor está disposto a processar. Reduza o tamanho do payload ou use envio fragmentado.
414
URI Too Long
O URL do pedido excede o limite do servidor. Encurte query strings ou mova dados para o corpo do pedido.
415
Unsupported Media Type
O servidor não suporta o Content-Type do pedido. Envie JSON, dados de formulário ou outro formato aceite pela API.
418
I'm a teapot
Definido na RFC 2324 como piada de 1 de Abril: o servidor recusa preparar café porque é um bule. Por vezes usado em demos.
422
Unprocessable Entity
O pedido é sintacticamente válido mas semanticamente incorrecto. Típico de erros de validação em APIs REST e formulários web.
429
Too Many Requests
O cliente enviou demasiados pedidos num intervalo de tempo. Respeite Retry-After e implemente backoff ou limitação de taxa.
5xx Erro do servidor
500
Internal Server Error
Ocorreu um erro inesperado no servidor. Normalmente não é culpa do cliente — verifique os logs do servidor e tente novamente mais tarde.
501
Not Implemented
O servidor não suporta a funcionalidade necessária para cumprir o pedido. O método ou funcionalidade não está implementado.
502
Bad Gateway
Um gateway ou proxy recebeu uma resposta inválida de um servidor upstream. Frequente atrás de balanceadores quando os backends falham.
503
Service Unavailable
O servidor está temporariamente indisponível, frequentemente por manutenção ou sobrecarga. Tente novamente após um atraso; verifique Retry-After se presente.
504
Gateway Timeout
Um gateway ou proxy não recebeu uma resposta atempada do servidor upstream. Indica lentidão do backend ou problemas de rede.
32 códigos de estado HTTP comuns
Sobre esta ferramenta
Browse HTTP status codes with this practical reference for API development and debugging. The HTTP status reference explains response classes and common edge cases from informational to server error codes.
Engineers use it to align backend behavior, frontend handling, and monitoring alerts around consistent semantics. Clear status code usage improves observability and client integration reliability.
Perguntas frequentes
- Why use an HTTP status reference during development?
- It helps choose correct response codes for each outcome so clients can handle success and failure conditions predictably.
- What is the difference between 4xx and 5xx?
- 4xx indicates client-side request issues, while 5xx indicates server-side failure or unavailable upstream behavior.
- Can this help improve API monitoring?
- Yes, understanding status semantics enables better alert thresholds and faster diagnosis of incident patterns.