Cómo evitar que un webhook duplicado rompa tu automatización

Meta y Chatwoot no esperan indefinidamente una respuesta. Si tu servidor tarda más de unos pocos segundos en responder a un webhook entrante, ambos lo interpretan como que la entrega falló y lo reintentan — Meta lo documenta explícitamente en su guía de webhooks de WhatsApp Cloud API. Desde el punto de vista de tu automatización, un único mensaje de un cliente real puede llegar como dos, tres o incluso más eventos "message_created" independientes.

Si tu flujo procesa cada evento como si fuera un mensaje nuevo, el resultado no es solo ineficiencia. Es corrupción real: el agente de IA responde el mismo mensaje varias veces, la memoria de la conversación se desordena porque dos ejecuciones paralelas escriben al mismo tiempo, y si el flujo dispara efectos secundarios —enviar una cotización, generar una factura, descontar inventario— esos efectos también se duplican.

Documentamos este mismo problema, de forma independiente, en dos agentes de WhatsApp completamente distintos —uno construido sobre n8n y Supabase, otro sobre un servidor Python propio detrás de Chatwoot self-hosted—. En ambos casos la causa raíz era la misma: no había una capa explícita de deduplicación entre "el webhook llegó" y "se ejecutó la lógica de negocio". El framework de orquestación (n8n en un caso, un loop propio en el otro) simplemente ejecutaba de nuevo cada evento que recibía, porque para él cada evento era indistinguible de uno nuevo.

La solución tiene dos partes que van juntas.

Responder en menos de cinco segundos, siempre. Antes de procesar nada, el servidor confirma recepción del webhook. En una implementación FastAPI, eso significa usar BackgroundTasks para encolar el procesamiento real y devolver el 200 OK de inmediato —nunca esperar a que termine la lógica de negocio antes de responder—.

Deduplicar de forma atómica, antes de que el mensaje entre al flujo del agente. Usamos una tabla de mensajes procesados con una inserción atómica del tipo INSERT ... ON CONFLICT DO NOTHING (o su equivalente Prefer: resolution=ignore-duplicates en PostgREST/Supabase), indexada por el ID único que cada proveedor asigna al mensaje. Si la inserción falla por duplicado, el evento se descarta ahí mismo, antes de tocar cualquier lógica de negocio. Esto tiene que ser atómico a nivel de base de datos —comparar "¿ya existe?" y luego insertar en dos pasos separados deja una ventana de carrera donde dos ejecuciones paralelas pasan la verificación al mismo tiempo—.

Un detalle adicional que también documentamos: si tu proceso de despliegue de workflows deduplica comparando solo la ruta del nodo webhook, un flujo sin webhook —por ejemplo uno disparado por cron— nunca se detecta como duplicado y puede terminar corriendo dos versiones en paralelo tras un redeploy. La deduplicación de infraestructura y la deduplicación de mensajes son dos problemas relacionados pero distintos, y hay que resolver los dos.