Saltar al contenido

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.

Tobias Krüger2 min de lectura
Dos sobres superpuestos y desplazados con los mismos símbolos morados de mensaje.

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

Escrito por

  • Tobias KrügerRedactor de integración de sistemasTobias Krüger se ocupa en ASES de cómo interactúan distintos sistemas de software. En sus artículos explica la conexión entre ERP, CRM y tiendas online, así como la gestión de errores en el intercambio de datos.

Seguir a ASES

Seguir leyendo

Todos los artículos

APIs e integración con ASES

ERP, CRM y tienda bien conectados