Protección contra entregas duplicadas
La mayoría de los sistemas vuelven a intentar enviar un webhook cuando no obtienen una respuesta rápida. Si el primer intento llegó efectivamente a su destino, su flujo de trabajo de Shopify Flow se ejecuta dos veces para un mismo evento: un segundo correo electrónico, una etiqueta duplicada o una nota de pedido repetida.
La protección contra envíos duplicados evita que eso ocurra. Está desactivada de forma predeterminada en todos los webhooks.
Cómo funciona
Si su sistema de envío incluye un identificador único por evento, indique el nombre del encabezado que lo contiene en «Configuración avanzada» -> «Detección de envíos duplicados».
| Comportamiento | |
|---|---|
| Primera solicitud con un identificador determinado | Si se procesa de forma habitual, los incendios se propagan. |
| Repítalo en un plazo de 24 horas | 200 OK con duplicate: true - no enviado a Shopify Flow |
| Un identificador diferente | Se ha tramitado con normalidad |
| Realice la solicitud sin ese encabezado | Se ha tramitado con normalidad |
| Campo sin rellenar | Se procesan todas las solicitudes; no hay cambios. |
Nombres habituales de encabezados: Event-Id, Idempotency-Key, X-Request-Id. La coincidencia no distingue entre mayúsculas y minúsculas.
# Same Event-Id twice - the second is accepted but not re-sent to Flow
curl -X POST https://your-app-url/webhook/ab12cd34 \
-H "Content-Type: application/json" \
-H "X-Api-Key: your-token" \
-H "Event-Id: evt_12345" \
-d '{"orderId":"1001"}'¿Por qué la repetición sigue devolviendo el código 200?
Una respuesta que no sea del código 2xx es precisamente lo que dificulta que el remitente vuelva a intentarlo. Responder con 200 le indica que el evento se ha gestionado correctamente, por lo que deja de intentarlo, mientras que incluir duplicate: true en el cuerpo de la respuesta le permite distinguir entre ambos resultados si registra las respuestas.
Dónde aparecen los duplicados
Un duplicado ocultado:
- No genera ninguna entrada en el historial de llamadas, por lo que no se contabiliza en su plan
- aparece en el «Live Request Inspector» mientras edita el webhook, marcado como duplicado eliminado
Esa combinación es intencionada: su historial y su cuota se mantienen intactos, pero nunca da la impresión de que una llamada haya desaparecido sin más.
Elegir el encabezado adecuado
El identificador debe mantenerse estable durante todo el proceso de reintento y ser único para cada evento; en eso consiste todo el mecanismo.
Correcto: un identificador de evento o una clave de idempotencia generada una sola vez por el remitente cuando se produce el evento.
Incorrecto y rechazado en el momento del almacenamiento: encabezados controlados por proxy, como X-Forwarded-For, CF-* o X-Signature. Su valor varía en cada solicitud o en cada salto, por lo que nunca coincidirían con una repetición, lo que provocaría un error silencioso en lugar de uno evidente.
Si el almacén de deduplicación no estuviera disponible durante un breve periodo de tiempo
La entrega se procesa en lugar de descartarse. La ejecución duplicada de un flujo de trabajo supone un problema mucho menor que la pérdida de un evento, por lo que la función se diseña para dar prioridad a la seguridad.

