Códigos de estado HTTP

Referencia completa de todos los códigos de estado HTTP con descripciones y ejemplos.

Mostrando 61 de 61

1xx Informativo

4 códigos de estado

100

Continuar

El servidor ha recibido los encabezados de la solicitud y el cliente debe proceder a enviar el cuerpo de la solicitud. Esto se utiliza para optimizar cargas grandes permitiendo al cliente verificar si el servidor aceptara la solicitud antes de enviar la carga completa.

Casos de uso comunes: Se utiliza cuando un cliente envia un encabezado Expect: 100-continue antes de cargar un cuerpo de solicitud grande, permitiendo al servidor rechazar la solicitud anticipadamente sin desperdiciar ancho de banda.

RFC 9110

101

Cambio de protocolos

El servidor esta cambiando a un protocolo diferente segun lo solicitado por el cliente a traves de un encabezado Upgrade. El servidor acepta y se comunicara usando el nuevo protocolo despues de esta respuesta.

Casos de uso comunes: Se observa con mayor frecuencia al actualizar una conexion HTTP a una conexion WebSocket. El cliente envia un encabezado Upgrade: websocket y el servidor responde con 101 para confirmar el cambio.

RFC 9110

102

Procesando

El servidor ha recibido y esta procesando la solicitud, pero aun no hay respuesta disponible. Esto evita que el cliente agote el tiempo de espera mientras el servidor trabaja en una operacion de larga duracion.

Casos de uso comunes: Se utiliza en operaciones WebDAV que pueden tardar mucho tiempo en completarse. Informa al cliente que el servidor no ha desconectado la conexion y sigue trabajando en la solicitud.

RFC 2518

103

Indicaciones tempranas

El servidor envia encabezados de respuesta preliminares antes de la respuesta final. Esto permite al cliente comenzar a precargar recursos mientras el servidor aun prepara la respuesta completa.

Casos de uso comunes: Se utiliza para enviar encabezados Link anticipadamente para que el navegador pueda precargar CSS, JavaScript o fuentes antes de que llegue la respuesta HTML final, mejorando el rendimiento de carga de la pagina.

RFC 8297

2xx Éxito

10 códigos de estado

200

OK

La solicitud ha tenido exito. El significado del exito depende del metodo HTTP: GET devuelve el recurso solicitado, POST devuelve el resultado de la accion, y asi sucesivamente.

Casos de uso comunes: La respuesta de exito estandar para la mayoria de las llamadas a la API. Se usa cuando una solicitud GET devuelve datos, una solicitud PUT actualiza un recurso o cualquier operacion se completa con exito con un cuerpo de respuesta.

RFC 9110

Solicitud

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}

201

Creado

La solicitud se ha cumplido y se ha creado un nuevo recurso. La respuesta generalmente incluye un encabezado Location que apunta al recurso recien creado.

Casos de uso comunes: Se devuelve despues de una solicitud POST exitosa que crea un nuevo recurso, como crear una nueva cuenta de usuario, agregar una publicacion de blog o cargar un archivo.

RFC 9110

Solicitud

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

Respuesta

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}

202

Aceptado

La solicitud ha sido aceptada para procesamiento, pero el procesamiento no se ha completado. La solicitud podria o no ser finalmente ejecutada, ya que podria ser rechazada cuando el procesamiento realmente tenga lugar.

Casos de uso comunes: Se utiliza para operaciones asincronas donde el servidor encola una tarea para procesamiento posterior, como enviar un correo electronico, generar un informe o activar un trabajo por lotes.

RFC 9110

203

Informacion no autoritativa

La solicitud fue exitosa pero los metadatos devueltos en los encabezados pueden provenir de una copia local o de terceros en lugar del servidor de origen. La carga incluida es una version modificada de la respuesta 200 del servidor de origen.

Casos de uso comunes: Raramente utilizado en la practica. Puede aparecer cuando un proxy transformador modifica los encabezados de respuesta del servidor de origen, indicando que los metadatos pueden no coincidir con el original.

RFC 9110

204

Sin contenido

El servidor ha cumplido la solicitud con exito y no hay contenido adicional para enviar en el cuerpo de la respuesta. La respuesta puede incluir encabezados actualizados.

Casos de uso comunes: Se devuelve despues de una solicitud DELETE exitosa, o una actualizacion PUT/PATCH donde no se necesita cuerpo de respuesta. Tambien se usa para operaciones de tipo disparar-y-olvidar donde una confirmacion es suficiente.

RFC 9110

Solicitud

DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 204 No Content

205

Restablecer contenido

El servidor ha cumplido la solicitud y desea que el agente de usuario restablezca la vista del documento que causo el envio de la solicitud. No se incluye cuerpo de respuesta.

Casos de uso comunes: Se utiliza para indicar al cliente que restablezca el formulario o la interfaz que envio la solicitud. Por ejemplo, despues de enviar un formulario con exito, el servidor puede senalar al navegador que limpie los campos del formulario.

RFC 9110

206

Contenido parcial

El servidor esta entregando solo parte del recurso debido a un encabezado Range enviado por el cliente. Esto se utiliza para descargas reanudables y transmision de medios.

Casos de uso comunes: Se utiliza cuando un cliente solicita un rango de bytes especifico de un archivo grande, habilitando funcionalidades como descargas reanudables, busqueda en videos y descargas paralelas por fragmentos.

RFC 9110

207

Multi-estado

Una respuesta WebDAV que transmite informacion sobre multiples recursos en situaciones donde multiples codigos de estado podrian ser apropiados. El cuerpo de la respuesta es un documento XML que contiene codigos de estado individuales para cada sub-solicitud.

Casos de uso comunes: Se utiliza en operaciones por lotes de WebDAV donde cada sub-operacion puede tener un resultado diferente. Por ejemplo, al copiar multiples archivos donde algunos tienen exito y otros fallan.

RFC 4918

208

Ya reportado

Se utiliza dentro de un elemento de respuesta DAV: propstat para evitar enumerar repetidamente los miembros internos de multiples enlaces a la misma coleccion.

Casos de uso comunes: Un estado WebDAV utilizado para evitar listar el mismo recurso multiples veces cuando aparece en multiples ubicaciones dentro de una coleccion debido a enlaces.

RFC 5842

226

IM utilizado

El servidor ha cumplido una solicitud GET para el recurso, y la respuesta es una representacion del resultado de una o mas manipulaciones de instancia aplicadas a la instancia actual.

Casos de uso comunes: Se utiliza con codificacion delta para enviar solo los cambios (deltas) entre la version actual de un recurso y una version previamente almacenada en cache, reduciendo el uso de ancho de banda.

RFC 3229

3xx Redirección

7 códigos de estado

300

Opciones multiples

El recurso de destino tiene mas de una representacion y el usuario o agente de usuario puede seleccionar una preferida. El servidor puede incluir una lista de las representaciones disponibles.

Casos de uso comunes: Raramente utilizado en la practica. Podria usarse cuando un recurso esta disponible en multiples formatos (por ejemplo, JSON, XML, HTML) y el servidor quiere que el cliente elija explicitamente.

RFC 9110

301

Movido permanentemente

Al recurso de destino se le ha asignado un nuevo URI permanente y cualquier referencia futura a este recurso deberia usar el URI Location devuelto. Los motores de busqueda actualizaran su indice.

Casos de uso comunes: Se utiliza cuando una pagina o punto final de API se ha movido permanentemente a una nueva URL. Esencial para SEO al reestructurar un sitio web, cambiar nombres de dominio o descontinuar patrones de URL antiguos.

RFC 9110

Solicitud

GET /old-page HTTP/1.1
Host: www.example.com

Respuesta

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html

<html><body>This page has moved to <a href="https://www.example.com/new-page">/new-page</a>.</body></html>

302

Encontrado

El recurso de destino reside temporalmente bajo un URI diferente. Como la redireccion puede ser modificada ocasionalmente, el cliente deberia seguir usando el URI original para solicitudes futuras.

Casos de uso comunes: Se utiliza para redirecciones temporales, como redirigir a una pagina de inicio de sesion, enviar usuarios a una pagina de mantenimiento o realizar pruebas A/B de diferentes versiones de pagina.

RFC 9110

Solicitud

GET /dashboard HTTP/1.1
Host: www.example.com

Respuesta

HTTP/1.1 302 Found
Location: https://www.example.com/login?redirect=/dashboard

303

Ver otro

El servidor esta redirigiendo al agente de usuario a un recurso diferente usando una solicitud GET, tipicamente despues de una operacion POST. Esto asegura que el cliente no reenvie los datos del formulario.

Casos de uso comunes: Se utiliza despues del envio de un formulario POST para redirigir a una pagina de confirmacion (el patron Post/Redirect/Get), evitando envios de formulario duplicados cuando el usuario actualiza la pagina.

RFC 9110

304

No modificado

El recurso no ha sido modificado desde la version especificada por los encabezados de solicitud If-Modified-Since o If-None-Match. El servidor no necesita enviar el cuerpo del recurso nuevamente.

Casos de uso comunes: Se devuelve cuando un cliente realiza una solicitud condicional y el recurso no ha cambiado, permitiendo al cliente usar su copia en cache. Esto ahorra ancho de banda y mejora los tiempos de carga.

RFC 9110

Solicitud

GET /api/users/42 HTTP/1.1
Host: api.example.com
If-None-Match: "etag-abc123"

Respuesta

HTTP/1.1 304 Not Modified
ETag: "etag-abc123"
Cache-Control: max-age=3600

307

Redireccion temporal

El recurso de destino reside temporalmente bajo un URI diferente y el agente de usuario no debe cambiar el metodo de solicitud al seguir la redireccion. A diferencia de 302, se garantiza que el metodo y el cuerpo permanezcan iguales.

Casos de uso comunes: Se utiliza cuando se necesita una redireccion temporal que preserve estrictamente el metodo HTTP. Por ejemplo, redirigir una solicitud POST a otro punto final sin cambiarla a GET.

RFC 9110

308

Redireccion permanente

Al recurso de destino se le ha asignado un nuevo URI permanente. Como 301, pero el metodo de solicitud y el cuerpo no deben cambiar al seguir la redireccion.

Casos de uso comunes: Se utiliza para redirecciones permanentes cuando es necesario preservar el metodo HTTP. Por ejemplo, redirigir permanentemente un punto final POST asegurando que los clientes sigan enviando solicitudes POST.

RFC 9110

4xx Error del cliente

29 códigos de estado

400

Solicitud incorrecta

El servidor no puede o no quiere procesar la solicitud debido a algo que se percibe como un error del cliente, como sintaxis de solicitud malformada, enmarcado de solicitud invalido o enrutamiento de solicitud enganoso.

Casos de uso comunes: Se devuelve cuando el cuerpo de la solicitud contiene JSON malformado, faltan campos obligatorios, los parametros de consulta son invalidos o la solicitud no se ajusta al formato esperado.

RFC 9110

Solicitud

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "",
  "email": "not-an-email"
}

Respuesta

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "validation_error",
  "message": "Request validation failed",
  "details": [
    { "field": "name", "message": "Name is required" },
    { "field": "email", "message": "Must be a valid email address" }
  ]
}

401

No autorizado

La solicitud no se ha aplicado porque carece de credenciales de autenticacion validas para el recurso de destino. La respuesta debe incluir un encabezado WWW-Authenticate indicando el esquema de autenticacion aplicable.

Casos de uso comunes: Se devuelve cuando una solicitud no tiene credenciales de autenticacion o el token/credenciales proporcionados estan caducados o son invalidos. El cliente necesita autenticarse antes de reintentar.

RFC 9110

Solicitud

GET /api/users/me HTTP/1.1
Host: api.example.com

Respuesta

HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer

{
  "error": "unauthorized",
  "message": "Authentication required. Please provide a valid Bearer token."
}

402

Pago requerido

Reservado para uso futuro. Originalmente destinado para esquemas de pago digital, este codigo de estado no esta ampliamente estandarizado pero a veces es utilizado por APIs para indicar que se requiere pago.

Casos de uso comunes: Aunque oficialmente reservado, algunas APIs lo utilizan para indicar que se requiere una funcion de pago o suscripcion, o que el usuario ha excedido los limites de uso de su nivel gratuito.

RFC 9110

403

Prohibido

El servidor entendio la solicitud pero se niega a autorizarla. A diferencia de 401, la autenticacion no ayudara. El cliente no tiene los permisos necesarios para el recurso.

Casos de uso comunes: Se devuelve cuando el usuario esta autenticado pero no tiene los permisos requeridos. Por ejemplo, un usuario regular intentando acceder a un punto final exclusivo para administradores, o accediendo a un recurso que pertenece a otro usuario.

RFC 9110

Solicitud

DELETE /api/users/99 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden",
  "message": "You do not have permission to delete this user. Admin role required."
}

404

No encontrado

El servidor de origen no encontro una representacion actual para el recurso de destino o no esta dispuesto a revelar que existe. Esto puede ser temporal o permanente.

Casos de uso comunes: El error mas comunmente encontrado. Se devuelve cuando el recurso solicitado no existe, como solicitar un usuario por un ID que no esta en la base de datos, o acceder a una URL sin ruta coincidente.

RFC 9110

Solicitud

GET /api/users/99999 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "not_found",
  "message": "User with ID 99999 was not found"
}

405

Metodo no permitido

El metodo recibido en la linea de solicitud es conocido por el servidor de origen pero no esta soportado por el recurso de destino. La respuesta debe incluir un encabezado Allow listando los metodos validos.

Casos de uso comunes: Se devuelve cuando el metodo HTTP no esta soportado para el punto final. Por ejemplo, enviar una solicitud DELETE a un recurso de solo lectura, o un POST a un punto final que solo soporta GET.

RFC 9110

Solicitud

DELETE /api/reports/monthly HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Allow: GET, HEAD

{
  "error": "method_not_allowed",
  "message": "DELETE is not allowed on this resource. Allowed methods: GET, HEAD"
}

406

No aceptable

El recurso de destino no tiene una representacion que sea aceptable para el agente de usuario, segun los encabezados de negociacion de contenido proactiva recibidos en la solicitud.

Casos de uso comunes: Se devuelve cuando el servidor no puede producir una respuesta que coincida con los encabezados Accept enviados por el cliente. Por ejemplo, un cliente solicita XML pero la API solo soporta JSON.

RFC 9110

407

Autenticacion de proxy requerida

Similar a 401, pero el cliente necesita autenticarse con el proxy. El proxy debe devolver un encabezado Proxy-Authenticate con el desafio aplicable.

Casos de uso comunes: Devuelto por un servidor proxy cuando el cliente no ha proporcionado credenciales validas para el proxy en si. Comun en entornos de red corporativos donde el trafico saliente pasa por un proxy autenticado.

RFC 9110

408

Tiempo de espera de solicitud agotado

El servidor no recibio un mensaje de solicitud completo dentro del tiempo que estaba preparado para esperar. El cliente puede repetir la solicitud sin modificaciones en cualquier momento posterior.

Casos de uso comunes: Se devuelve cuando el cliente tarda demasiado en enviar la solicitud completa. Puede ocurrir con conexiones lentas, cargas grandes sobre redes poco fiables o cuando un cliente abre una conexion pero no envia datos.

RFC 9110

409

Conflicto

La solicitud no se pudo completar debido a un conflicto con el estado actual del recurso de destino. El cliente deberia poder resolver el conflicto y reenviar la solicitud.

Casos de uso comunes: Se utiliza cuando una solicitud entra en conflicto con datos existentes, como crear un usuario con un correo electronico que ya existe, o intentar actualizar un recurso que ha sido modificado por otra solicitud desde la ultima vez que se obtuvo.

RFC 9110

Solicitud

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

Respuesta

HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "conflict",
  "message": "A user with email jane@example.com already exists",
  "existing_id": 42
}

410

Desaparecido

El recurso de destino ya no esta disponible en el servidor de origen y es probable que esta condicion sea permanente. A diferencia de 404, esto indica explicitamente que el recurso existio pero ha sido eliminado intencionalmente.

Casos de uso comunes: Se utiliza cuando un recurso ha sido deliberada y permanentemente eliminado. Senala a los motores de busqueda que deben eliminar la URL de su indice, a diferencia de 404 que puede ser temporal.

RFC 9110

411

Longitud requerida

El servidor rechaza aceptar la solicitud sin un encabezado Content-Length definido. El cliente puede repetir la solicitud si se agrega un encabezado Content-Length valido.

Casos de uso comunes: Se devuelve cuando el servidor requiere que el encabezado Content-Length este presente en la solicitud, tipicamente para cargas o solicitudes POST donde el servidor necesita conocer el tamano de la carga por adelantado.

RFC 9110

412

Precondicion fallida

Una o mas condiciones dadas en los campos de encabezado de la solicitud se evaluaron como falsas al probarse en el servidor. Se utiliza con solicitudes condicionales como If-Match o If-Unmodified-Since.

Casos de uso comunes: Se devuelve cuando una actualizacion condicional falla porque el recurso ha sido modificado desde la ultima vez que el cliente lo obtuvo. Se utiliza para implementar control de concurrencia optimista en APIs.

RFC 9110

413

Contenido demasiado grande

El servidor se niega a procesar la solicitud porque la carga de la solicitud es mas grande de lo que el servidor esta dispuesto o es capaz de procesar. El servidor puede cerrar la conexion o devolver un encabezado Retry-After.

Casos de uso comunes: Se devuelve cuando una carga de archivo o cuerpo de solicitud excede el limite de tamano maximo configurado del servidor, como cargar un archivo de 100 MB a un punto final con un limite de 10 MB.

RFC 9110

414

URI demasiado largo

El servidor se niega a atender la solicitud porque el objetivo de la solicitud es mas largo de lo que el servidor esta dispuesto a interpretar. Esto puede ocurrir cuando una solicitud GET tiene parametros de consulta excesivamente largos.

Casos de uso comunes: Se devuelve cuando la URL excede la longitud maxima del servidor. Esto ocurre frecuentemente cuando se codifican demasiados datos en parametros de consulta en lugar de enviarlos en un cuerpo de solicitud POST.

RFC 9110

415

Tipo de medio no soportado

El servidor de origen se niega a atender la solicitud porque la carga esta en un formato no soportado por este metodo en el recurso de destino. El Content-Type o Content-Encoding no es aceptable.

Casos de uso comunes: Se devuelve cuando el servidor no soporta el Content-Type enviado en la solicitud. Por ejemplo, enviar datos form-urlencoded a un punto final que solo acepta application/json.

RFC 9110

416

Rango no satisfactorio

El conjunto de rangos en el campo de encabezado Range de la solicitud ha sido rechazado porque ninguno de los rangos solicitados es satisfactorio para la representacion seleccionada.

Casos de uso comunes: Se devuelve cuando un cliente solicita un rango de bytes que cae fuera del tamano del recurso, como solicitar los bytes 1000-2000 de un archivo de 500 bytes.

RFC 9110

417

Expectativa fallida

La expectativa dada en el campo de encabezado Expect de la solicitud no pudo ser cumplida por al menos uno de los servidores entrantes.

Casos de uso comunes: Se devuelve cuando el servidor no puede cumplir los requisitos especificados en el encabezado Expect. Mas comunmente relacionado con el mecanismo Expect: 100-continue cuando el servidor rechaza la solicitud antes de que se envie el cuerpo.

RFC 9110

418

Soy una tetera

Cualquier intento de preparar cafe con una tetera deberia resultar en este codigo de error. Esto fue definido en el Hyper Text Coffee Pot Control Protocol como una broma del Dia de los Inocentes pero se ha preservado como curiosidad cultural.

Casos de uso comunes: Un codigo de estado Easter egg de un RFC del Dia de los Inocentes. A veces se usa con humor en APIs como una respuesta divertida, o como un rechazo deliberado a procesar una solicitud que el servidor considera absurda.

RFC 2324

421

Solicitud mal dirigida

La solicitud fue dirigida a un servidor que no es capaz de producir una respuesta. Esto puede ocurrir cuando un servidor no esta configurado para producir respuestas para la combinacion de esquema y autoridad en el URI de la solicitud.

Casos de uso comunes: Puede ocurrir en HTTP/2 cuando una conexion se reutiliza para un nombre de host diferente que el servidor no puede manejar. El cliente deberia reintentar la solicitud en una conexion diferente.

RFC 9110

422

Contenido no procesable

El servidor entiende el tipo de contenido y la sintaxis de la solicitud es correcta, pero no pudo procesar las instrucciones contenidas. La solicitud esta bien formada pero es semanticamente invalida.

Casos de uso comunes: Se utiliza cuando el cuerpo de la solicitud es JSON sintacticamente valido pero falla la validacion de logica de negocio. Por ejemplo, establecer un precio negativo, programar una reunion en el pasado o proporcionar una fecha de fin anterior a la fecha de inicio.

RFC 9110

Solicitud

POST /api/events HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "Team Meeting",
  "start_date": "2025-12-01",
  "end_date": "2025-11-01"
}

Respuesta

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "unprocessable_entity",
  "message": "Semantic validation failed",
  "details": [
    { "field": "end_date", "message": "End date must be after start date" }
  ]
}

423

Bloqueado

El recurso de origen o destino de un metodo esta bloqueado. El cliente deberia intentar de nuevo mas tarde o solicitar un desbloqueo.

Casos de uso comunes: Se utiliza en WebDAV cuando un recurso esta bloqueado por otro usuario o proceso. Tambien puede usarse en APIs para indicar que un recurso esta temporalmente bloqueado para edicion por otro usuario.

RFC 4918

424

Dependencia fallida

El metodo no se pudo ejecutar en el recurso porque la accion solicitada dependia de otra accion que fallo.

Casos de uso comunes: Se utiliza en WebDAV cuando una operacion falla porque una operacion prerequisito de la que depende tambien fallo. Por ejemplo, la copia de un directorio falla porque la copia de uno de los archivos hijos fallo.

RFC 4918

425

Demasiado temprano

El servidor no esta dispuesto a arriesgarse a procesar una solicitud que podria ser repetida, para evitar posibles ataques de repeticion al usar TLS 1.3 early data (0-RTT).

Casos de uso comunes: Se utiliza cuando una solicitud llega en TLS 1.3 early data (0-RTT) y el servidor no puede garantizar que no ha sido ya procesada. Previene ataques de repeticion en solicitudes no idempotentes.

RFC 8470

426

Actualizacion requerida

El servidor se niega a ejecutar la solicitud usando el protocolo actual pero podria estar dispuesto a hacerlo despues de que el cliente actualice a un protocolo diferente. El servidor debe incluir un encabezado Upgrade indicando el protocolo requerido.

Casos de uso comunes: Se utiliza cuando el servidor requiere que el cliente cambie a una version de protocolo mas reciente, como actualizar de HTTP/1.1 a HTTP/2, o de una conexion no cifrada a TLS.

RFC 9110

428

Precondicion requerida

El servidor de origen requiere que la solicitud sea condicional. Esto esta destinado a prevenir el problema de la actualizacion perdida donde un cliente obtiene un recurso con GET, lo modifica y lo envia con PUT mientras otro cliente tambien lo ha modificado.

Casos de uso comunes: Se devuelve cuando el servidor requiere encabezados condicionales como If-Match o If-Unmodified-Since para prevenir problemas de modificacion concurrente. Obliga a los clientes a implementar bloqueo optimista.

RFC 6585

429

Demasiadas solicitudes

El usuario ha enviado demasiadas solicitudes en un periodo de tiempo dado (limitacion de tasa). La respuesta deberia incluir un encabezado Retry-After indicando cuanto tiempo esperar antes de hacer una nueva solicitud.

Casos de uso comunes: Se devuelve cuando el cliente excede el limite de tasa de la API. La mayoria de las APIs usan esto para proteger contra abuso y asegurar un uso justo. Los clientes deben retroceder y reintentar despues del tiempo especificado en el encabezado Retry-After.

RFC 6585

Solicitud

GET /api/search?q=test HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Respuesta

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Maximum 100 requests per minute.",
  "retry_after": 60
}

431

Campos de encabezado de solicitud demasiado grandes

El servidor no esta dispuesto a procesar la solicitud porque sus campos de encabezado son demasiado grandes. La solicitud puede ser reenviada despues de reducir el tamano de los campos de encabezado de la solicitud.

Casos de uso comunes: Se devuelve cuando los encabezados de solicitud exceden los limites de tamano del servidor. Esto ocurre comunmente cuando las cookies crecen demasiado, o cuando se pasan demasiados datos en encabezados personalizados o un token de autorizacion sobredimensionado.

RFC 6585

451

No disponible por razones legales

El servidor deniega el acceso al recurso como consecuencia de una demanda legal. La respuesta deberia incluir una explicacion de la restriccion legal en el cuerpo y un encabezado Link para identificar la autoridad legal.

Casos de uso comunes: Se utiliza cuando un recurso esta bloqueado debido a requisitos legales como ordenes de censura gubernamental, avisos de retiro DMCA, ordenes judiciales o cumplimiento de sanciones. El numero de codigo hace referencia a Fahrenheit 451.

RFC 7725

5xx Error del servidor

11 códigos de estado

500

Error interno del servidor

El servidor encontro una condicion inesperada que le impidio cumplir la solicitud. Este es un error generico de tipo comodin cuando ningun codigo de estado 5xx mas especifico es apropiado.

Casos de uso comunes: El error de servidor mas comun. Se devuelve cuando el servidor encuentra una excepcion no controlada, un error, un fallo de conexion a la base de datos o cualquier otro problema inesperado durante el procesamiento de la solicitud.

RFC 9110

Respuesta

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "internal_server_error",
  "message": "An unexpected error occurred. Please try again later.",
  "request_id": "req_abc123xyz"
}

501

No implementado

El servidor no soporta la funcionalidad requerida para cumplir la solicitud. Esta es la respuesta apropiada cuando el servidor no reconoce el metodo de solicitud y no es capaz de soportarlo.

Casos de uso comunes: Se devuelve cuando el servidor no reconoce o aun no ha implementado el metodo HTTP solicitado. Puede usarse como marcador de posicion para puntos finales de API que estan planeados pero aun no construidos.

RFC 9110

502

Puerta de enlace incorrecta

El servidor, actuando como puerta de enlace o proxy, recibio una respuesta invalida de un servidor ascendente al que accedio para intentar cumplir la solicitud.

Casos de uso comunes: Devuelto por proxys inversos, balanceadores de carga o puertas de enlace API cuando el servidor de aplicacion ascendente envia una respuesta malformada, se cae o no es accesible. Comun durante despliegues.

RFC 9110

Respuesta

HTTP/1.1 502 Bad Gateway
Content-Type: application/json

{
  "error": "bad_gateway",
  "message": "The upstream server returned an invalid response. Please try again shortly."
}

503

Servicio no disponible

El servidor actualmente no puede manejar la solicitud debido a sobrecarga temporal o mantenimiento programado. La implicacion es que esta es una condicion temporal y el servidor estara disponible de nuevo pronto.

Casos de uso comunes: Se devuelve durante ventanas de mantenimiento planificadas, cuando el servidor esta sobrecargado o cuando una dependencia critica esta caida. El encabezado Retry-After puede indicar cuando el cliente deberia intentar de nuevo.

RFC 9110

Respuesta

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300

{
  "error": "service_unavailable",
  "message": "Service is temporarily unavailable for scheduled maintenance. Expected back at 2025-12-01T03:00:00Z.",
  "retry_after": 300
}

504

Tiempo de espera de puerta de enlace agotado

El servidor, actuando como puerta de enlace o proxy, no recibio una respuesta oportuna de un servidor ascendente al que necesitaba acceder para completar la solicitud.

Casos de uso comunes: Devuelto por proxys inversos o balanceadores de carga cuando el servidor de aplicacion ascendente tarda demasiado en responder. A menudo indica una consulta de base de datos lenta, un tiempo de espera de API externa o un backend sobrecargado.

RFC 9110

505

Version HTTP no soportada

El servidor no soporta, o se niega a soportar, la version mayor de HTTP que fue usada en el mensaje de solicitud.

Casos de uso comunes: Se devuelve cuando el servidor no soporta la version del protocolo HTTP utilizada en la solicitud, como un servidor que solo soporta HTTP/1.1 recibiendo una solicitud HTTP/2 que no puede manejar.

RFC 9110

506

La variante tambien negocia

El servidor tiene un error de configuracion interna: el recurso variante elegido esta configurado para participar el mismo en la negociacion de contenido transparente, resultando en una referencia circular.

Casos de uso comunes: Un error raro que indica una mala configuracion en la negociacion de contenido del lado del servidor, donde el recurso negociado intenta a su vez negociar, creando un bucle infinito.

RFC 2295

507

Almacenamiento insuficiente

El metodo no se pudo ejecutar en el recurso porque el servidor es incapaz de almacenar la representacion necesaria para completar la solicitud con exito.

Casos de uso comunes: Un estado WebDAV devuelto cuando el servidor se queda sin espacio en disco o cuota de almacenamiento al intentar escribir datos. Tambien puede aplicarse a APIs donde se ha alcanzado un limite de almacenamiento.

RFC 4918

508

Bucle detectado

El servidor termino una operacion porque encontro un bucle infinito al procesar una solicitud con Depth: infinity. Esta es una version mas especifica de 500.

Casos de uso comunes: Un estado WebDAV devuelto cuando el servidor detecta una dependencia circular o bucle infinito en los enlaces de recursos, como una estructura de directorio que se referencia a si misma.

RFC 5842

510

No extendido

La politica para acceder al recurso no se ha cumplido en la solicitud. El servidor deberia enviar toda la informacion necesaria para que el cliente emita una solicitud extendida.

Casos de uso comunes: Un codigo de estado raramente utilizado que indica que se requieren extensiones adicionales a la solicitud para que el servidor la cumpla. Definido en la especificacion HTTP Extension Framework.

RFC 2774

511

Autenticacion de red requerida

El cliente necesita autenticarse para obtener acceso a la red. Esto no se trata de autenticacion a nivel HTTP sino de acceso a nivel de red, como iniciar sesion en un portal cautivo.

Casos de uso comunes: Devuelto por portales cautivos (por ejemplo, paginas de inicio de sesion de Wi-Fi de hotel o aeropuerto) cuando el usuario aun no se ha autenticado con la red. El cuerpo de la respuesta tipicamente contiene una pagina de inicio de sesion.

RFC 6585

Guías relacionadas

36 encabezados

Encabezados HTTP

Encabezados HTTP comunes explicados con sintaxis, ejemplos y valores frecuentes.

Explorar

9 métodos

Métodos HTTP

Guía completa de métodos de solicitud HTTP con tablas comparativas y ejemplos.

Explorar

70 tipos MIME

Tipos MIME

Referencia completa de tipos MIME comunes con extensiones de archivo, categorías y ejemplos de uso.

Explorar

10 encabezados

CORS explicado

Guía completa de Cross-Origin Resource Sharing — cómo funciona, cada encabezado explicado y errores comunes con soluciones.

Explorar

Pruébalo en RequestDock

Envía solicitudes HTTP reales e inspecciona las respuestas — directamente en tu navegador.

Abrir RequestDock