Un reintento nunca debería convertirse de forma silenciosa en un recibo diferente. Si un proceso en Node sufre un timeout y el siguiente intento lee una plantilla recién modificada o valores de pedido que han cambiado, el equipo dejará de tener claro qué mensaje recibió realmente el cliente.
Diseña y aprueba el recibo en Migma; después, coordínate con los responsables de Node y de Loops para conservar los datos de negocio originales y conciliar los envíos con estado incierto. Esta guía, publicada por Migma, se centra en el acuerdo operativo en torno a los creativos durante los reintentos, sin entrar en configuraciones de integraciones de entrega ni asumir que Migma gestiona Loops de forma automática.
Determina qué constituye el mismo mensaje
Imagina un pedido ficticio de dos cuadernos. El recibo previsto especifica los artículos, los importes aprobados y la referencia del pedido. Estos datos describen un evento de negocio concreto. Si más adelante se tramita un reembolso o una corrección de dirección, se trata de una modificación que conviene tratar de forma explícita, en lugar de introducirla en un reintento sin revisión previa.
Registra un documento breve que recoja lo que el primer envío debía comunicar: la referencia del evento, el destinatario previsto, la versión aprobada de la plantilla, las variables obligatorias y el responsable de cada dato. Evita incluir información personal o de pago innecesaria en las notas de revisión del diseño.
La pregunta clave no es simplemente «¿se ha vuelto a ejecutar el código?», sino «¿el nuevo intento busca comunicar el mismo evento aprobado a la misma persona?». Si la respuesta cambia, deja de tratar la acción como un reintento convencional y consulta con el responsable correspondiente cómo debe gestionarse esa corrección.
Separa la aprobación del diseño de la identidad del envío
El flujo de trabajo documentado de Migma permite preparar textos, diseño, imágenes y una estructura HTML optimizada para clientes de correo antes de pasar a revisión. Esto resulta ideal para consensuar la maquetación y la redacción del recibo, pero no determina qué petición aceptó el proveedor ni si el cliente ya ha recibido el mensaje.
Conserva el diseño aprobado junto con el mapeo entre eventos y plantillas. Si en destino se utiliza una plantilla compartida en Loops, define cómo controla la implementación los cambios mientras haya envíos pendientes. Guardar una captura de pantalla local no implica que la plantilla utilizada por la aplicación quede congelada.
Revisa tanto el contenido informativo como los enlaces de acción. Un botón de estado del pedido debe dirigir a la misma compra que detalla el recibo; un enlace genérico que diga «Ver pedido» no neutraliza el error si la URL de destino es incorrecta. Pide al responsable de la integración que valide ejemplos con datos reales y no solo nombres de variables vacíos.
Aplica el contrato de reintentos actual del proveedor
El recurso sobre Node de Loops aborda el envío transaccional y la gestión de reintentos. Para conocer el comportamiento exacto del servicio, consulta la documentación del endpoint transaccional, verificada para esta guía el 17 de octubre de 2026.
Dicho endpoint contempla un encabezado opcional Idempotency-Key para evitar peticiones duplicadas, así como una respuesta 409 cuando una clave ya se ha utilizado dentro de su ventana temporal. El responsable del envío debe aplicar este contrato de forma rigurosa. Generar una clave nueva simplemente para saltarse un conflicto puede anular la protección contra duplicados que el equipo pretendía mantener.
Este artículo no proporciona código de reintentos ni fórmulas universales para el control de errores. Corresponde al equipo de ingeniería definir cómo se registran y concilian los fallos temporales, los definitivos y las respuestas ambiguas. La revisión de diseño debe limitarse a aportar los datos estables que este proceso necesita, sin inventar estados de entrega paralelos.
Evalúa tres escenarios antes de pasar a producción
Ante un reintento sin cambios, confirma que el evento previsto, el destinatario, los valores y el contenido revisado sigan siendo exactamente los mismos. Comprueba cómo vincula el proceso esa versión aprobada y cómo podrá auditarse más adelante la respuesta del proveedor.
Ante un recibo modificado, identifica con precisión qué ha variado y por qué motivo. Una cantidad corregida, un reembolso o un cambio de destinatario pueden exigir una comunicación aprobada de forma independiente. Evita reescribir el significado del primer mensaje solo para que la última captura encaje visualmente.
Ante una respuesta incierta, mantén ese estado hasta que el emisor lo concilie. Un timeout de conexión no demuestra que el proveedor haya rechazado la petición. No permitas que la prisa de marketing por «asegurarse de que llegue» desencadene un segundo envío no revisado a través de otra vía.
Valida el renderizado final del recibo
Toma la exportación HTML de Migma como referencia creativa validada. El responsable de Loops debe confirmar el procedimiento admitido para implementar esa plantilla y rellenar sus variables. Esta guía no presupone una integración nativa directa entre Migma y Loops.
Prueba el recibo en casos complejos: con varios artículos, con nombres de producto largos, con valores opcionales ausentes o tras una modificación del pedido. Los datos obligatorios de una transacción no deben reemplazarse con suposiciones verosímiles; si falta un dato clave, el responsable de negocio debe determinar si el mensaje puede enviarse con garantías de exactitud.
Ejecuta Email Preflight para verificar textos, enlaces, diseño y previsualizaciones en diferentes bandejas de entrada. A continuación, apóyate en el entorno de pruebas controlado del equipo técnico para validar la plantilla final y los casos de reintento. Una comprobación visual en el editor no certifica la aceptación por parte del proveedor ni garantiza la entregabilidad.
Mantén las correcciones visibles para todo el equipo
Agrupa en un mismo lugar el contenido aprobado, el mapeo de eventos, los casos de prueba y la asignación del responsable de conciliación. Si la plantilla compartida sufre cambios, analiza con el equipo técnico el impacto sobre los procesos en cola antes de asumir que solo afectará a envíos futuros.
El objetivo es contar con un recibo que todo el equipo pueda justificar: qué comunica, qué evento describe y qué evidencias técnicas respaldan su estado. Diseña el contenido en Migma y vincula las decisiones sobre reintentos a los registros reales del proveedor y de la aplicación.
Preguntas frecuentes
¿Un timeout confirma que el recibo no se ha enviado?
No. La respuesta puede quedar en un estado incierto incluso si el proveedor aceptó la solicitud. El responsable del envío debe conciliar el resultado real antes de autorizar un nuevo intento.
¿Conviene generar una clave nueva tras recibir un error 409 de Loops?
No utilices una clave distinta únicamente para sortear el conflicto. Revisa las especificaciones actuales del endpoint y concilia el evento original, la petición y la respuesta del proveedor con el equipo técnico.
¿Aprobar una captura en Migma bloquea la plantilla en Loops?
No. Es necesario definir cómo hacen referencia al contenido aprobado tanto la plantilla en destino como los procesos pendientes. Una captura sirve como referencia de revisión, no como mecanismo de control sobre un sistema de envío externo.
¿Un recibo modificado se considera un reintento ordinario?
Cualquier cambio en el destinatario, los datos de negocio o el propósito del mensaje exige una revisión explícita. El responsable correspondiente debe determinar si se trata de una corrección o de una comunicación independiente, en lugar de alterar el contenido del envío original de forma desapercibida.