miji.beEl reintento de webhook es un mecanismo que, cuando falla la entrega de un webhook que notifica a sistemas externos eventos como los clics en URLs cortas, la reenvía dejando un intervalo determinado. Se usa para hacer llegar más tarde las entregas que fallaron por problemas de red o por un tiempo de inactividad temporal del lado receptor.
Una de las formas de decidir el tiempo de espera de los reintentos es el retroceso exponencial (Exponential Backoff). El tiempo de espera aumenta de forma exponencial: 1 segundo tras el primer fallo, 2 segundos tras el segundo, 4 segundos tras el tercero, 8 segundos tras el cuarto... Con ello, es menos probable que los reenvíos se acumulen sobre un receptor sobrecargado. Si se añade jitter (una fluctuación aleatoria), es menos probable que los reenvíos de varios webhooks se concentren en el mismo momento.
Los casos de uso típicos de los webhooks en un acortador de URL son (1) la integración de los eventos de clic con el CRM (lead scoring), (2) las notificaciones a Slack/Teams (supervisión de campañas en tiempo real), (3) la acumulación de eventos en un almacén de datos (plataforma de análisis) y (4) las alertas de seguridad (detección de patrones de clic sospechosos).
Una consideración de diseño importante es garantizar la idempotencia (Idempotency). Como los reintentos pueden hacer que un mismo evento se entregue varias veces, el lado receptor necesita implementar la eliminación de duplicados mediante el ID del evento. También hace falta diseñar el número máximo de reintentos y la Dead Letter Queue (el lugar donde se apartan los eventos que al final no se pueden entregar). En la documentación para desarrolladores de Stripe (a octubre de 2026), los reenvíos en el entorno de producción duran como máximo 3 días. En la descripción de la Events API de Slack (a octubre de 2026), se reenvía como máximo 3 veces (casi de inmediato, al cabo de 1 minuto y al cabo de 5 minutos).