Qué pasa si falla el aviso de una multa por webhook

Muchos contratos de avisos de multas prometen “entrega garantizada”. La expresión sugiere que cada evento va a llegar siempre, una sola vez y a tiempo. Ningún sistema distribuido puede sostener esa lectura: el endpoint receptor vive en la infraestructura del cliente, y entre productor y consumidor hay DNS, certificados, balanceadores, despliegues y timeouts.

La pregunta útil no es si una entrega va a fallar, sino qué pasa con el acta cuando falla. Entrega garantizada, bien entendida, es un compromiso verificable: reintentos con un calendario conocido, retención con un plazo definido y una vía de reenvío y reconciliación cuando todo lo anterior se agota.

Qué cuenta como entregado

El productor considera entregada el acta cuando recibe una respuesta de éxito. La semántica HTTP define clases de códigos: los de éxito indican que la solicitud fue recibida y aceptada; los de error del servidor, que el receptor no pudo procesarla. Un timeout o una conexión cortada no dicen nada: el receptor pudo haber procesado el evento y perdido la respuesta.

Por eso el contrato debe fijar dos cosas: qué códigos cuentan como confirmación y cuánto espera el productor antes de dar el intento por fallido. Un 200 tampoco significa “procesado”: significa que el receptor aceptó la solicitud. Lo que hace después con ella es responsabilidad del consumidor, un problema tratado en idempotencia, reintentos y trazabilidad.

La ventana de reintentos

Cuando no hay confirmación, el productor reintenta. Un buen calendario espacia los intentos con esperas crecientes y algo de dispersión, para no golpear un endpoint que está intentando recuperarse. También distingue causas: un fallo transitorio, como un timeout o una indisponibilidad, justifica volver a intentar; un rechazo estable de autenticación o de esquema no se arregla repitiendo la misma solicitud.

Lo que define la garantía no es la existencia de reintentos sino su ventana publicada. El consumidor necesita saber cuánto puede durar una caída de su endpoint sin perder el aviso de un acta: minutos, horas o días. Ese dato decide qué urgencia tiene una alerta de infraestructura y si hace falta una cola intermedia propia.

Agotados los reintentos, el evento no desaparece

La diferencia entre entrega garantizada y un intento cortés está acá. Cuando la ventana se agota, el acta debería quedar retenida, marcada como fallida y visible: una lista de entregas pendientes que el consumidor pueda revisar, con la causa del último intento.

La retención también tiene plazo, y el contrato debe decirlo. Un evento retenido conserva su identidad: CloudEvents define id y source como atributos obligatorios cuya combinación identifica cada evento, y contempla que un duplicado reenviado mantenga el mismo id. Un reenvío días después no crea un hecho nuevo: el consumidor lo reconoce y aplica el efecto una sola vez.

Reenvío y reconciliación

El reenvío del acta, manual desde un panel o automático tras la recuperación, llega tarde y a veces desordenado. El consumidor debe poder verificar que es auténtico y no una repetición maliciosa capturada en tránsito. RFC 9421 define cómo firmar componentes de un mensaje HTTP y cómo declarar cuándo se creó la firma y cuándo expira. Con esa base, un reenvío legítimo se distingue de un replay: la firma es válida y reciente aunque el evento sea viejo. El orden tampoco vuelve solo: un lote reenviado puede mezclar días distintos, y conviene reconstruir el estado sin confiar en la llegada.

Aun así, ningún calendario cubre todo: un endpoint que responde éxito pero descarta por un bug, una retención vencida durante una caída larga, una suscripción mal configurada. La garantía se cierra con una vía de consulta: pedir las actas de un período o desde un cursor y comparar contra lo recibido. Un polling lento y bien diseñado funciona como red de contención del webhook, no como su reemplazo.

Qué verificar en un contrato de webhooks

Antes de dar por garantizada la entrega, confirmá en el contrato:

qué códigos de respuesta cuentan como confirmación y cuál es el timeout por intento;
el calendario de reintentos completo y su duración total;
el plazo de retención de eventos fallidos y cómo se listan;
si existe reenvío, quién puede dispararlo y cómo se autentica;
la vía de reconciliación para comparar lo emitido contra lo recibido.

Un proveedor que responde esas cinco preguntas con valores concretos ofrece una garantía auditable. Uno que sólo repite “entrega garantizada” ofrece una frase.

Metodología

Alcance: Contratos de entrega de webhooks entre un proveedor de notificaciones de infracciones y el endpoint de una empresa; no cubre la lógica interna de procesamiento del consumidor.
Unidad de análisis: Un evento lógico y sus intentos de entrega HTTP, desde la emisión hasta la confirmación, el reenvío o el vencimiento de la retención.
Cobertura: Semántica derivada de los estándares citados de HTTP, firmas de mensajes y CloudEvents; los plazos concretos dependen de cada contrato.

Limitaciones

Los calendarios de reintentos, plazos de retención y mecanismos de reenvío varían por proveedor y no surgen de un estándar único.
Las firmas y la deduplicación protegen la entrega, pero no garantizan que el consumidor procese correctamente el evento.
La reconciliación depende de que el productor exponga una vía de consulta por período o cursor, que no siempre existe.

Fuentes

RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
CloudEvents specification — Cloud Native Computing Foundation (consultada el 2026-08-29)
RFC 9421 — HTTP Message Signatures — RFC Editor (consultada el 2026-08-29)

Preguntas frecuentes

¿“Entrega garantizada” significa que el evento llega exactamente una vez?

No. En la práctica significa al menos una vez dentro de una ventana de reintentos y retención. El mismo evento puede llegar repetido y el consumidor debe reconocerlo por su identificador para aplicar el efecto una sola vez.

¿Cuánto tiempo reintenta un proveedor si mi endpoint está caído?

Depende de cada contrato: no existe un plazo estándar. Lo verificable es que el calendario esté publicado, con cantidad de intentos, esperas y duración total, para dimensionar alertas y colas propias.

¿Un reenvío manual crea un evento nuevo?

No debería. Si el productor conserva la identidad del evento, el reenvío mantiene el mismo identificador y el consumidor puede deduplicarlo. CloudEvents contempla que un duplicado reenviado conserve su id.

¿Qué pasa si venció la retención y perdí eventos?

Queda la reconciliación: consultar los eventos de un período o desde un cursor y comparar contra lo recibido. Por eso conviene que el contrato ofrezca esa vía de consulta además del webhook.

Entrega garantizada: qué pasa si el aviso de una multa falla