Las integraciones webhook necesitan reglas para las repeticiones
El efecto de los webhooks repetidos debe controlarse. Un acuse de recibo perdido no debe provocar otro pedido sin comprobación.

Al planificar una integración webhook, conviene tratar las entregas repetidas como una condición de funcionamiento posible. La decisión de software debe contemplar qué ocurre con la acción de negocio cuando el mensaje llega por segunda vez. Una conexión fiable no responde por sí sola a esa pregunta.
Una señal perdida deja el resultado incierto
En un portal de clientes ficticio, una notificación inicia la creación de un pedido en el ERP. El pedido se crea, pero la respuesta no llega al remitente. Este vuelve a enviar la notificación. Si cada llegada genera ciegamente un pedido nuevo, una misma acción produce dos pedidos.
Stripe indica expresamente que los eventos pueden entregarse más de una vez. Esto acredita un caso concreto de un proveedor. Debe consultar el contrato de su propia conexión para determinar qué repeticiones puede producir. La ausencia de un acuse de recibo no permite deducir ni un éxito seguro ni un fallo seguro.
Evaluar la repetición por su efecto de negocio
En el ejemplo, la regla deseada permite que la misma notificación encuentre el pedido ya creado en lugar de crear otro. La integración necesita una identidad acordada y una asociación fiable con el resultado del procesamiento. La protección también debe contemplar dos copias que llegan simultáneamente; comprobar y guardar después, en pasos independientes, deja esa cuestión sin resolver.
En el escenario de aceptación, compruebe el pedido en el ERP, la respuesta al reintento y el estado visible en el portal. Un acuse de transporte y un pedido completado pueden representar estados diferentes.
El esfuerzo depende de la acción
Si una notificación solo vuelve a asignar el mismo valor mostrado, repetirla puede ser inocuo. La creación de un pedido u otro efecto que deba producirse una sola vez necesita más protección. Esto no obliga a añadir una cola adicional a cada conexión pequeña.
Las repeticiones deben seguir siendo visibles. Un aumento puede indicar una incidencia. Recomendamos gestionar las repeticiones esperables y conservar la capacidad de investigar patrones inusuales.
Fuentes
Seguir leyendo
Todos los artículos




APIs e integración con ASES
ERP, CRM y tienda bien conectados

