{"id":23370,"date":"2026-09-21T21:11:02","date_gmt":"2026-09-21T21:11:02","guid":{"rendered":"https:\/\/indigitall.com\/?p=23370"},"modified":"2026-09-22T08:08:44","modified_gmt":"2026-09-22T08:08:44","slug":"como-integrar-api-whatsapp-business-retail-ecommerce","status":"publish","type":"post","link":"https:\/\/indigitall.com\/es\/como-integrar-api-whatsapp-business-retail-ecommerce\/","title":{"rendered":"C\u00f3mo integrar la API de WhatsApp Business en retail y ecommerce: las decisiones de datos que se toman antes del primer mensaje"},"content":{"rendered":"
\n

TL;DR:<\/strong> Integrar WhatsApp en una tienda no es conectar un canal, es decidir cinco cosas antes de escribir la primera l\u00ednea de c\u00f3digo: qu\u00e9 sistema manda sobre cada dato, c\u00f3mo se reconoce al mismo comprador cuando entra por cuatro puertas, qu\u00e9 eventos abren conversaci\u00f3n, qu\u00e9 viaja con la conversaci\u00f3n cuando cambia de manos y qui\u00e9n la mantiene cuando cambie el cat\u00e1logo. La parte t\u00e9cnica es la f\u00e1cil. Lo que rompe las integraciones de ecommerce es dar por hecho que los eventos llegan siempre, y la documentaci\u00f3n de Shopify lo desmiente con todas las letras: la entrega de webhooks no est\u00e1 garantizada y recomienda procesos de conciliaci\u00f3n. Una panader\u00eda espa\u00f1ola con presencia nacional que mont\u00f3 su gesti\u00f3n de pedidos sobre WhatsApp lo hizo as\u00ed y en sus primeros 15 meses resolvi\u00f3 el 65% de las consultas con el bot y un 40% m\u00e1s r\u00e1pido que por correo. Esta gu\u00eda va por ese orden y termina con las 6 pruebas que hay que pasar antes de abrir el canal.<\/p>\n<\/blockquote>\n

Este art\u00edculo es para quien va a montar o rehacer la integraci\u00f3n de WhatsApp en una tienda con pedidos, cat\u00e1logo y atenci\u00f3n, en M\u00e9xico o en cualquier operaci\u00f3n que venda en l\u00ednea y en piso. Al terminar vas a tener la lista de decisiones de datos que hay que cerrar antes de empezar, y las pruebas concretas que distinguen una integraci\u00f3n que aguanta una temporada alta de una que se cae en la primera.<\/p>\n

\u00bfQu\u00e9 tiene que conectar la integraci\u00f3n, exactamente?<\/h2>\n

La respuesta corta son 7 cosas, y conviene escribirlas antes de elegir proveedor porque cada una vive en un sistema distinto y cada una tiene un due\u00f1o distinto dentro de la empresa.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Dato<\/th>\nPara qu\u00e9 hace falta en la conversaci\u00f3n<\/th>\nD\u00f3nde suele vivir<\/th>\n<\/tr>\n<\/thead>\n
Cliente<\/td>\nSaber con qui\u00e9n hablas antes de leer el mensaje<\/td>\nCRM o plataforma de datos<\/td>\n<\/tr>\n
Pedido<\/td>\nResponder d\u00f3nde est\u00e1 el paquete sin preguntar<\/td>\nEcommerce o ERP<\/td>\n<\/tr>\n
Cat\u00e1logo<\/td>\nQue la plantilla no mencione un producto retirado<\/td>\nEcommerce o PIM<\/td>\n<\/tr>\n
Consentimiento<\/td>\nSaber si puedes mandar promoci\u00f3n o solo servicio<\/td>\nPlataforma de datos<\/td>\n<\/tr>\n
Estado de entrega<\/td>\nAvisar sin que el cliente lo pida<\/td>\nTransportista o ERP<\/td>\n<\/tr>\n
Estado de la conversaci\u00f3n<\/td>\nSaber si hay una ventana abierta y qui\u00e9n atiende<\/td>\nPlataforma de mensajer\u00eda<\/td>\n<\/tr>\n
Resultado<\/td>\nCerrar el ciclo y poder medir<\/td>\nPlataforma de datos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Si alguno de esos 7 no est\u00e1 conectado, la integraci\u00f3n funciona igual. Simplemente responde peor, y el s\u00edntoma no aparece el primer d\u00eda: aparece semanas despu\u00e9s, en forma de agente preguntando por el n\u00famero de pedido que el cliente ya escribi\u00f3 tres mensajes antes.<\/p>\n

N\u00f3tese una cosa en la tabla: solo dos de los siete viajan en los dos sentidos. El consentimiento y el resultado. Son justo los dos que casi nunca se devuelven al sistema de origen, y por eso la ficha del cliente envejece mal aunque la integraci\u00f3n est\u00e9 viva.<\/p>\n

\n

\ud83d\uddbc\ufe0f Visual suggestion \u2014 diagrama:<\/strong> Mapa de los 7 datos con su sistema de origen y el sentido en que viajan. Inserta aqu\u00ed diagrama.<\/strong>
\nBrief de dise\u00f1o:<\/em> Columna izquierda con 4 cajas de sistema: CRM, ecommerce, transportista, plataforma de datos. Columna derecha, una sola caja alta etiquetada "conversaci\u00f3n". Entre ambas, 7 l\u00edneas etiquetadas con el nombre del dato. Las de consentimiento y resultado con punta de flecha en los dos extremos y en color de marca; las otras cinco en gris y en un solo sentido.
\nAlt:<\/em> Mapa de los siete datos que alimentan una conversaci\u00f3n de WhatsApp en retail, con su sistema de origen y el sentido en que viaja cada uno.
\nPie:<\/em> S\u00f3lo dos de los siete vuelven al sistema de origen. Son los dos que deciden si la ficha del cliente mejora con cada conversaci\u00f3n o se queda como estaba.<\/p>\n<\/blockquote>\n

\u00bfQu\u00e9 sistema manda sobre cada dato?<\/h2>\n

Esta es la decisi\u00f3n que m\u00e1s discusiones evita y la que casi nunca se escribe. Cuando dos sistemas pueden modificar el mismo campo, uno tiene que ganar siempre, y eso se decide antes, no cuando aparece el conflicto a las tres semanas.<\/p>\n

La regla que funciona en tiendas es simple: manda el sistema donde el dato nace<\/strong>. El pedido manda el ecommerce. El precio manda el cat\u00e1logo. El estado de entrega manda el transportista. Y el consentimiento manda la plataforma de datos, porque es la \u00fanica que lo ve entrar y salir por todos los canales a la vez.<\/p>\n

El caso que rompe la regla es el nombre del cliente, porque lo toca todo el mundo: el checkout, el punto de venta, el propio cliente cuando lo corrige por chat. Ah\u00ed hay que elegir a mano y escribirlo. Si no, cada sincronizaci\u00f3n lo pisa y acabas mandando mensajes con tres versiones distintas del mismo nombre.<\/p>\n

Hay una segunda regla que se olvida y que en ecommerce vale oro: cada handler tiene que ser idempotente<\/strong>. Si el mismo evento llega dos veces, el resultado tiene que ser el mismo que si hubiera llegado una. Sin eso, un reintento normal del ecommerce se convierte en un cliente duplicado o en dos avisos de env\u00edo para el mismo paquete.<\/p>\n

Esa capa de decisi\u00f3n es la que resuelve un CDP<\/a> y es lo que separa una integraci\u00f3n de un mont\u00f3n de conexiones sueltas. Es el mismo problema que aparece al juntar marketing automatizado con un CRM unificado<\/a>: sin una fuente de verdad declarada, las dos herramientas se corrigen entre ellas y ninguna gana.<\/p>\n

\n

\ud83d\uddbc\ufe0f Visual suggestion \u2014 tabla visual:<\/strong> Tabla de fuente de verdad, dato por dato. Inserta aqu\u00ed tabla visual.<\/strong>
\nBrief de dise\u00f1o:<\/em> Tabla de dos columnas y 6 filas: pedido, precio, estado de entrega, consentimiento, tel\u00e9fono, nombre. A la derecha el sistema que manda. La fila del nombre marcada con un icono de interrogaci\u00f3n y una nota al pie: "se decide a mano y se escribe".
\nAlt:<\/em> Tabla que asigna a cada dato de la conversaci\u00f3n el sistema que manda sobre \u00e9l, con el nombre del cliente marcado como el \u00fanico que hay que decidir a mano.
\nPie:<\/em> Cinco de los seis tienen due\u00f1o evidente. El nombre no lo tiene, y por eso es el que acaba escrito de tres formas distintas si nadie decide antes.<\/p>\n<\/blockquote>\n

\u00bfPor qu\u00e9 los eventos no siempre llegan, y qu\u00e9 se hace al respecto?<\/h2>\n

Esta es la parte que casi ning\u00fan art\u00edculo sobre integraciones de WhatsApp menciona, y es la que m\u00e1s silenciosamente falla.<\/p>\n

Un aviso de pedido no llega porque tu ecommerce lo mande. Llega si tu endpoint estaba levantado, si respondi\u00f3 a tiempo, si nadie despleg\u00f3 nada en ese minuto y si la red se port\u00f3. La documentaci\u00f3n de Shopify sobre webhooks<\/a> lo dice sin adornos: "Your app shouldn't rely on receiving data from Shopify webhooks. Webhook delivery isn't guaranteed"<\/em>, y recomienda expl\u00edcitamente "use reconciliation jobs to periodically fetch data"<\/em> para mantener la consistencia.<\/p>\n

Traducido a una tienda: adem\u00e1s de escuchar eventos, hay que preguntar. Un proceso que cada cierto tiempo compare los pedidos de las \u00faltimas horas contra los avisos que salieron y rellene los huecos.<\/p>\n

Sin eso, el d\u00eda que la integraci\u00f3n tenga 20 minutos malos, unos cuantos cientos de clientes se quedan sin su aviso de env\u00edo y nadie se entera<\/strong>, porque un evento que no lleg\u00f3 no deja rastro en ning\u00fan sitio. No hay error, no hay alerta, no hay fila roja en un panel. Hay silencio, y el silencio se parece mucho a que todo va bien.<\/p>\n

Ese es tambi\u00e9n el motivo por el que conviene tratar la integraci\u00f3n como una m\u00e1quina de estados y no como un bot\u00f3n que funciona: cada pedido est\u00e1 en un estado, cada estado tiene los avisos que le corresponden, y la conciliaci\u00f3n comprueba que el estado y los avisos cuadran. Es m\u00e1s trabajo al montarlo y es lo \u00fanico que permite responder a la pregunta inc\u00f3moda de "\u00bfcu\u00e1ntos avisos se perdieron el mes pasado?" con un n\u00famero en vez de con un encogimiento de hombros.<\/p>\n

\n

\ud83d\uddbc\ufe0f Visual suggestion \u2014 diagrama:<\/strong> Dos caminos hacia el mismo aviso, el evento y la conciliaci\u00f3n. Inserta aqu\u00ed diagrama.<\/strong>
\nBrief de dise\u00f1o:<\/em> Arriba, una l\u00ednea de eventos con 6 puntos, dos tachados con una cruz para representar entregas perdidas. Abajo, una l\u00ednea de conciliaci\u00f3n peri\u00f3dica con una lupa que recoge los dos puntos tachados y los reenv\u00eda. Las dos confluyen en una caja etiquetada "aviso enviado". A la derecha, un contador etiquetado "avisos perdidos el mes pasado: 0".
\nAlt:<\/em> Diagrama con dos caminos hacia el aviso al cliente, los eventos en tiempo real y un proceso de conciliaci\u00f3n peri\u00f3dica que recupera los que no llegaron.
\nPie:<\/em> La conciliaci\u00f3n no es una optimizaci\u00f3n. Es lo \u00fanico que convierte "creo que no se perdi\u00f3 nada" en un n\u00famero que se puede ense\u00f1ar.<\/p>\n<\/blockquote>\n

\u00bfC\u00f3mo se evita que el mismo comprador acabe siendo tres fichas?<\/h2>\n

En retail esto pasa siempre, y no por descuido: pasa porque el mismo comprador entra por puertas distintas.<\/p>\n

Compra como invitado con un correo. Vuelve dos semanas despu\u00e9s y se registra con otro. Escribe a WhatsApp desde el n\u00famero de su pareja. Y en la tienda f\u00edsica da un tel\u00e9fono sin lada. Cuatro entradas y, si nadie decide qu\u00e9 las une, cuatro fichas y cuatro historiales.<\/p>\n

La regla de uni\u00f3n tiene que estar escrita antes de abrir el canal. En M\u00e9xico conviene ser expl\u00edcito con el tel\u00e9fono, porque es donde m\u00e1s se duplica: mismo pa\u00eds, mismos 10 d\u00edgitos, con o sin el 52 delante y con o sin el 1 hist\u00f3rico que todav\u00eda arrastran muchas bases. Un n\u00famero guardado de dos formas distintas es la causa m\u00e1s com\u00fan de ficha duplicada y tambi\u00e9n la m\u00e1s barata de arreglar si se decide al principio.<\/p>\n

Y hay que decidir adem\u00e1s el orden de prioridad cuando dos entradas se contradicen. Si el tel\u00e9fono del checkout y el del punto de venta no coinciden, \u00bfcu\u00e1l se queda? No hay una respuesta universal, hay que elegir una y respetarla.<\/p>\n

Cuando la tienda vive en dos mundos, el de piso y el de l\u00ednea, el problema se dobla. Es lo que trabaja una estrategia de clicks to bricks<\/a>: si el perfil no sobrevive al salto entre canales, la conversaci\u00f3n empieza de cero cada vez y el cliente lo nota antes que t\u00fa.<\/p>\n

\n

\ud83d\uddbc\ufe0f Visual suggestion \u2014 infograf\u00eda:<\/strong> Las cuatro entradas del mismo comprador y la regla que las une. Inserta aqu\u00ed infograf\u00eda.<\/strong>
\nBrief de dise\u00f1o:<\/em> Cuatro iconos de entrada a la izquierda: compra como invitado, registro, mensaje de WhatsApp, alta en tienda f\u00edsica. Cuatro flechas que convergen en una caja central etiquetada "regla de uni\u00f3n" y una sola salida a una ficha \u00fanica. Bajo la caja central, tres l\u00edneas peque\u00f1as: tel\u00e9fono normalizado a 10 d\u00edgitos, correo en min\u00fasculas, prioridad declarada.
\nAlt:<\/em> Las cuatro formas en que el mismo comprador entra en los sistemas de una tienda y la regla de uni\u00f3n que las convierte en una sola ficha.
\nPie:<\/em> La regla de uni\u00f3n no se descubre, se declara. Si no est\u00e1 escrita antes de abrir el canal, cada entrada nueva crea una ficha y el historial deja de servir para nada.<\/p>\n<\/blockquote>\n

<\/p>\n

\n