DEV Community

Cover image for ¿Qué es httpbin? Endpoints, cómo usarlo y alternativas
Roobia
Roobia

Posted on • Originally published at apidog.com

¿Qué es httpbin? Endpoints, cómo usarlo y alternativas

Si necesitas probar un cliente HTTP sin levantar un backend real, httpbin es una opción directa: envías una solicitud y el servicio te devuelve lo que recibió. Úsalo para inspeccionar encabezados, validar cuerpos JSON, probar códigos 500, simular timeouts o comprobar que un token de autenticación llega correctamente. Puedes llamarlo desde un comando curl, desde tests automatizados o desde un cliente API como Apidog. La instancia pública está en httpbin.org y el proyecto es open source bajo licencia ISC.

Prueba Apidog hoy

¿Qué es httpbin?

httpbin es un servicio HTTP de solicitud-respuesta. Le envías una petición y devuelve una descripción JSON de lo que recibió: método, encabezados, parámetros, cuerpo, IP de origen y otros datos según el endpoint.

Fue creado por Kenneth Reitz, autor de la biblioteca Python requests, y está escrito en Python con Flask.

El caso de uso principal es depurar clientes HTTP sin depender de una API real. Por ejemplo, si quieres verificar que tu cliente envía correctamente un encabezado User-Agent, llamas a:

curl https://httpbin.org/headers
Enter fullscreen mode Exit fullscreen mode

La respuesta muestra los encabezados que el servidor recibió. No necesitas base de datos, autenticación, fixtures ni configuración de backend.

La instancia pública httpbin.org sirve para pruebas rápidas, pero puede estar lenta o no disponible porque es un servicio gratuito y compartido. Para pruebas frecuentes, CI o tráfico privado, conviene autoalojarlo con Docker.

Endpoints útiles de httpbin

httpbin organiza sus pruebas en endpoints específicos. Estos son los más prácticos para desarrollo y testing:

Endpoint Para qué sirve
/get Devuelve query params, encabezados e IP de origen de una solicitud GET
/post Devuelve datos de formulario, cuerpo JSON y encabezados enviados por POST
/put, /patch, /delete Reflejan solicitudes con otros métodos HTTP
/status/{codes} Devuelve el código HTTP indicado, por ejemplo /status/404 o /status/503
/headers Devuelve solo los encabezados recibidos
/ip Devuelve la IP de origen
/user-agent Devuelve el User-Agent enviado por el cliente
/delay/{n} Espera n segundos antes de responder, hasta 10 segundos
/basic-auth/{user}/{passwd} Devuelve 200 si las credenciales Basic Auth coinciden
/bearer Comprueba si existe un token Bearer en Authorization
/redirect/{n} Ejecuta n redirecciones
/cookies Devuelve las cookies enviadas
/uuid Devuelve un UUID aleatorio
/anything Devuelve todo sobre la solicitud, sin importar el método

Los endpoints más útiles para probar clientes robustos suelen ser:

  • /status/{code} para validar manejo de errores.
  • /delay/{n} para probar timeouts.
  • /headers para comprobar autenticación y metadatos.
  • /anything para inspeccionar solicitudes completas.

Si además necesitas respuestas falsas con estructura de negocio, combina httpbin con una API falsa para datos de prueba.

Cómo usar httpbin con curl

1. Probar parámetros de consulta

Envía una solicitud GET con query params:

curl "https://httpbin.org/get?tool=apidog&check=headers"
Enter fullscreen mode Exit fullscreen mode

La respuesta incluye una sección args:

{
  "args": {
    "check": "headers",
    "tool": "apidog"
  },
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "curl/8.0.1"
  },
  "origin": "203.0.113.10",
  "url": "https://httpbin.org/get?tool=apidog&check=headers"
}
Enter fullscreen mode Exit fullscreen mode

Úsalo para confirmar que tu cliente está construyendo correctamente la URL.

2. Probar envío de JSON

Envía un cuerpo JSON con Content-Type explícito:

curl -X POST "https://httpbin.org/post" \
  -H "Content-Type: application/json" \
  -d '{"name": "widget", "qty": 3}'
Enter fullscreen mode Exit fullscreen mode

httpbin devuelve el JSON parseado en la propiedad json:

{
  "json": {
    "name": "widget",
    "qty": 3
  }
}
Enter fullscreen mode Exit fullscreen mode

Esto permite verificar tres cosas:

  • El cuerpo llegó completo.
  • El Content-Type era correcto.
  • El cliente no modificó la carga útil.

3. Probar encabezados personalizados 

curl "https://httpbin.org/headers" \
  -H "X-Request-ID: test-123" \
  -H "Authorization: Bearer demo-token"
Enter fullscreen mode Exit fullscreen mode

Revisa que X-Request-ID y Authorization aparezcan en la respuesta. Es útil para depurar middleware, interceptores, gateways o clientes generados.

4. Forzar errores HTTP

Para probar cómo responde tu código ante un error 503:

curl -i "https://httpbin.org/status/503"
Enter fullscreen mode Exit fullscreen mode

Verás una respuesta real:

HTTP/2 503
Enter fullscreen mode Exit fullscreen mode

Puedes cambiar el código según el caso:

curl -i "https://httpbin.org/status/400"
curl -i "https://httpbin.org/status/401"
curl -i "https://httpbin.org/status/429"
curl -i "https://httpbin.org/status/500"
Enter fullscreen mode Exit fullscreen mode

Esto sirve para validar ramas de error que normalmente son difíciles de reproducir contra una API real.

5. Simular respuestas lentas 

curl -i "https://httpbin.org/delay/5"
Enter fullscreen mode Exit fullscreen mode

El servidor esperará 5 segundos antes de responder. Úsalo para probar:

  • timeouts del cliente;
  • cancelación de requests;
  • reintentos;
  • circuit breakers;
  • manejo de loading states en frontend.

Ejemplo: probar lógica de reintentos en JavaScript

Puedes usar httpbin para validar que tu cliente reintenta ante respuestas 5xx.

async function fetchWithRetry(url, retries = 3) {
  for (let attempt = 1; attempt <= retries; attempt++) {
    const response = await fetch(url);

    if (response.ok) {
      return response;
    }

    if (response.status >= 500 && attempt < retries) {
      continue;
    }

    throw new Error(`Request failed with status ${response.status}`);
  }
}

fetchWithRetry("https://httpbin.org/status/503")
  .then(() => console.log("OK"))
  .catch((error) => console.error(error.message));
Enter fullscreen mode Exit fullscreen mode

Con /status/503 puedes comprobar que el código entra en la ruta de retry sin depender de que una API real falle.

Ejemplo: probar timeout con JavaScript 

async function fetchWithTimeout(url, timeoutMs = 2000) {
  const controller = new AbortController();

  const timeout = setTimeout(() => {
    controller.abort();
  }, timeoutMs);

  try {
    return await fetch(url, {
      signal: controller.signal
    });
  } finally {
    clearTimeout(timeout);
  }
}

fetchWithTimeout("https://httpbin.org/delay/5", 2000)
  .then((response) => console.log(response.status))
  .catch((error) => console.error("Timeout o cancelación:", error.name));
Enter fullscreen mode Exit fullscreen mode

Aquí /delay/5 fuerza una respuesta más lenta que el timeout configurado.

Usar httpbin desde Apidog

No tienes que limitarte a la terminal. Cualquier cliente REST puede llamar a las mismas URLs.

En Apidog, puedes hacer una prueba rápida así:

  1. Crea una nueva solicitud.
  2. Usa el método GET.
  3. Introduce la URL: 
   https://httpbin.org/get
Enter fullscreen mode Exit fullscreen mode
  1. Añade query params, encabezados o body según lo que quieras probar.
  2. Envía la solicitud.
  3. Inspecciona la respuesta JSON.

Esto es útil si quieres guardar la prueba, reutilizar variables de entorno o compartir el request con tu equipo.

Por ejemplo, para probar autenticación Bearer:

GET https://httpbin.org/bearer
Authorization: Bearer demo-token
Enter fullscreen mode Exit fullscreen mode

httpbin responderá indicando si el token fue recibido. Para flujos más orientados a terminal, también puedes revisar estos clientes TUI REST API.

Autoalojar httpbin con Docker

La instancia pública de httpbin.org está bien para comprobaciones puntuales, pero no es ideal para CI o pruebas repetibles. Puede tener latencia, límites o caídas temporales.

Para ejecutar tu propia instancia, usa Docker:

docker pull kennethreitz/httpbin
docker run -p 80:80 kennethreitz/httpbin
Enter fullscreen mode Exit fullscreen mode

Luego llama al servicio local:

curl http://localhost/get
Enter fullscreen mode Exit fullscreen mode

Si el puerto 80 está ocupado, usa otro puerto de host:

docker run -p 8080:80 kennethreitz/httpbin
Enter fullscreen mode Exit fullscreen mode

Y prueba:

curl http://localhost:8080/get
Enter fullscreen mode Exit fullscreen mode

La imagen está publicada en Docker Hub como kennethreitz/httpbin.

Cuándo conviene autoalojarlo

Autoaloja httpbin cuando:

  • tus pruebas corren en CI;
  • no quieres depender de un servicio externo;
  • necesitas resultados más estables;
  • quieres mantener tráfico de prueba dentro de tu red;
  • ejecutas muchas solicitudes repetidas.

Un ejemplo típico en CI sería levantar el contenedor antes de ejecutar tests de integración:

docker run -d --name httpbin -p 8080:80 kennethreitz/httpbin

curl --fail http://localhost:8080/status/200
Enter fullscreen mode Exit fullscreen mode

Casos prácticos de prueba

Validar que un SDK envía headers correctos

Usa:

https://httpbin.org/headers
Enter fullscreen mode Exit fullscreen mode

Comprueba headers como:

  • Authorization;
  • Content-Type;
  • Accept;
  • User-Agent;
  • X-Request-ID;
  • headers de tracing.

Validar serialización de JSON

Usa:

https://httpbin.org/post
Enter fullscreen mode Exit fullscreen mode

Envía el body desde tu cliente y verifica que aparezca en json.

Validar manejo de errores

Usa:

https://httpbin.org/status/400
https://httpbin.org/status/401
https://httpbin.org/status/429
https://httpbin.org/status/500
Enter fullscreen mode Exit fullscreen mode

Cada endpoint te permite probar una rama distinta de error.

Validar redirecciones

Usa:

curl -i "https://httpbin.org/redirect/3"
Enter fullscreen mode Exit fullscreen mode

Si quieres que curl siga redirecciones:

curl -L "https://httpbin.org/redirect/3"
Enter fullscreen mode Exit fullscreen mode

Validar cookies 

curl "https://httpbin.org/cookies" \
  --cookie "session_id=abc123"
Enter fullscreen mode Exit fullscreen mode

La respuesta mostrará las cookies recibidas.

Alternativas a httpbin

httpbin es útil, pero no es una plataforma completa de testing. Estas alternativas cubren necesidades relacionadas.

Postman Echo

Postman Echo es un servicio alojado similar a httpbin. Puedes llamar a:

https://postman-echo.com/get
Enter fullscreen mode Exit fullscreen mode

Devuelve información sobre la solicitud recibida. Cubre GET, POST, autenticación y endpoints de utilidad. Consulta la documentación de Postman Echo para ver la lista completa.

Si httpbin.org está caído, Postman Echo puede servir como sustituto rápido.

httpbin autoalojado

Si necesitas exactamente los endpoints de httpbin pero con más control, ejecuta la imagen Docker. Es la mejor opción para redes privadas, pruebas internas y CI.

Servicios de mock

httpbin refleja tu solicitud, pero no genera datos de dominio realistas. Si necesitas respuestas como usuarios, pedidos, productos o resultados paginados, usa un servidor mock.

Apidog incluye mocking inteligente basado en esquemas, lo que permite desarrollar un frontend contra endpoints simulados antes de que el backend esté listo.

Apidog como cliente y capa de pruebas

httpbin es el destino al que envías solicitudes. Apidog es la herramienta para diseñarlas, ejecutarlas y convertirlas en pruebas repetibles.

Puedes usar Apidog para:

  • enviar solicitudes a httpbin;
  • guardar requests;
  • reutilizar variables de entorno;
  • escribir aserciones;
  • encadenar solicitudes;
  • ejecutar escenarios de prueba;
  • trabajar con mocks cuando un simple eco no sea suficiente.

Cuando pases de llamadas curl ad-hoc a pruebas compartidas, Apidog te permite importar solicitudes existentes y añadir validaciones. Para más opciones sin instalación, revisa estas herramientas gratuitas de prueba de API en línea.

Preguntas frecuentes

¿httpbin es gratuito?

Sí. La instancia pública de httpbin.org es gratuita y no requiere cuenta. El código fuente es abierto bajo licencia ISC, por lo que también puedes ejecutarlo por tu cuenta.

¿httpbin se sigue manteniendo?

La base de código está en el repositorio postmanlabs/httpbin. Ha recibido mantenimiento intermitente, por lo que para usos importantes conviene fijar una versión autoalojada con Docker.

¿Puedo usar httpbin para probar webhooks?

No es la herramienta ideal. httpbin devuelve solicitudes que le envías, pero no actúa como túnel hacia tu máquina local ni como receptor especializado de eventos externos.

Para ese caso, usa herramientas de túnel o inspección de webhooks. Puedes revisar esta guía sobre pruebas de API y webhooks en localhost y esta introducción sobre cómo funcionan los webhooks.

¿Cuál es la diferencia entre httpbin y Postman Echo?

Ambos devuelven tu solicitud HTTP como JSON. httpbin es el servicio original open source en Python y Flask. Postman Echo es un servicio alojado por Postman. Para pruebas rápidas, usa el que esté disponible y responda mejor desde tu entorno.

¿Puedo probar manejo de errores con httpbin?

Sí. Usa /status/{code} para forzar códigos como:

/status/400
/status/401
/status/429
/status/500
/status/503
Enter fullscreen mode Exit fullscreen mode

Y usa /delay/{n} para simular respuestas lentas:

/delay/5
Enter fullscreen mode Exit fullscreen mode

Es una forma simple de probar reintentos, timeouts y fallback logic.

Conclusión

httpbin es una herramienta pequeña pero muy práctica para probar clientes HTTP. Usa /get y /post para inspeccionar lo que envías, /headers para depurar autenticación y metadatos, /status/{code} para forzar errores y /delay/{n} para validar timeouts.

Para pruebas puntuales, la instancia pública funciona bien. Para CI o flujos repetibles, ejecuta tu propia instancia con Docker.

Cuando necesites guardar solicitudes, compartirlas con tu equipo, añadir aserciones o reemplazar ecos simples por mocks realistas, una plataforma completa como Apidog puede cubrir ese flujo. Puedes descargar Apidog y convertir comprobaciones rápidas con httpbin en pruebas reutilizables.

Top comments (0)