Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

webhook-lab

Webhook Lab es un local webhook debugger para desarrolladores Python que captura, inspecciona y reproduce eventos HTTP con escenarios de fallo y historial de entrega.

Ficha actualizada 23 sept 2026, 0:54 · upstream 23 sept 2026, 0:45 · release sin release detectada

Ver códigoProblemas y ayudaRepositorio ↗Sitio oficial
00

Qué es webhook-lab

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

Webhook Lab es una herramienta basada en FastAPI y SQLite diseñada para permitir a los desarrolladores capturar, inspeccionar y reproducir eventos HTTP de webhook. La aplicación permite iniciar un entorno local donde se puede enviar un evento, examinar su payload original y sus encabezados sanitizados, así como seguir el historial completo de intentos de entrega desde el fallo hasta la recuperación. El proyecto está construido con Python 3.12+ y utiliza PostgreSQL para persistencia de datos.

CASOS DE USO
  • Capturar un evento de webhook (ej: order.created) y examinar su payload original antes de que sea procesado por un receptor externo.
  • Simular fallos en el destino del webhook (503, 429) para entender cómo se comporta el sistema ante errores de red o recursos agotados.
  • Reproducir secuencias completas de eventos: desde la creación hasta la confirmación de entrega, incluyendo transiciones de estado como 'pending' → 'processing' → 'delivered'.
  • Analizar el historial de intentos fallidos para identificar patrones recurrentes y optimizar la estrategia de retry.
  • Validar que los encabezados sanitizados se aplican correctamente antes de enviar un evento a cualquier servicio externo.
  • Probar escenarios de red complejos como timeouts, redirects o conexiones fallidas en el destino del webhook.
PUNTOS DESTACADOS
  • Soporta múltiples intentos de entrega con deduplicación automática basada en IDempotency-Key y X-Webhook-Lab-Event-Id.
  • Permite capturar y reproducir eventos completos incluyendo cuerpo, headers sanitizados, timestamps y historial de intentos.
  • Diseñado para uso local (single-user, in-process) con persistencia en SQLite, sin necesidad de infraestructura externa.
  • Soporta múltiples destinos configurables mediante un objeto JSON simple, permitiendo pruebas con servicios reales o simulados.
  • Incluye documentación interactiva en /docs y ejemplos de configuración para diferentes escenarios de red.
PRECAUCIONES
  • No ofrece deduplicación automática ni garantiza exactamente-once delivery; los eventos pueden repetirse si se envían múltiples veces.
  • La persistencia se realiza con SQLite, lo que limita la escalabilidad a un solo usuario y no soporta transacciones duraderas.
  • Los encabezados de autorización, cookies y firmas del proveedor no se transmiten en el replay, requiriendo adaptadores adicionales para servicios que los exigen.
  • No incluye persistencia duradera (PostgreSQL), migraciones ni un worker dedicado para manejar múltiples eventos simultáneamente.
  • La deduplicación se realiza solo por IDempotency-Key y X-Webhook-Lab-Event-Id, lo que puede no cubrir escenarios de red complejos con headers personalizados.
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU2 vCPUrecomendación inicial
MEMORIA2 GBRAM estimada
DISCO20 GBalmacenamiento base
COMPLEJIDADmediumnivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Listo para automatizar

Para desplegar Webhook Lab en producción, se recomienda usar Docker Compose. Se debe configurar un entorno aislado (VPC o subred privada) y asignar IPs públicas a los servicios. Los endpoints del webhook deben estar configurados en el firewall con reglas de seguridad correspondientes. Para pruebas de integración, se puede configurar un servicio externo como un endpoint REST público que acepte POSTs con headers sanitizados. Se recomienda implementar un worker de background para manejar múltiples eventos simultáneamente y una estrategia de retry basada en políticas de red (timeout, jitter) antes de enviar al destino final.

✓Dockerfile
✓Compose
✓One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
Next.jsFastAPIPython
SERVICIOS
PostgreSQL
BASES DE DATOS
PostgreSQL
PUERTOS
80009001
05

Puede sustituir a

Relaciones detectadas por el análisis del repositorio y su categoría.

06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.