Si la base de acceso está mal, WhatsApp deja de ayudar y pasa a meter riesgo. Yo lo resumiría así: para conectar una tienda con WhatsApp API necesito definir activos de Meta, usuarios del sistema, tokens, webhooks firmados, plantillas aprobadas y roles con límites claros.
En pocas palabras, este esquema tiene que cubrir 6 frentes:
hub.verify_token en el alta y con X-Hub-Signature-256 en cada POST.También hay un punto simple, pero muchas veces olvidado: si en el checkout no guardo el teléfono con prefijo país, como +54, no hay automatización que funcione bien.
Si uso Shopify, Tiendanube, VTEX o un stack propio, la idea no cambia demasiado. Y si uso Burbuxa, antes de conectar tengo que definir quién autoriza el acceso y qué datos se sincronizan: productos, pedidos, clientes, inventario, descuentos y políticas.
Para no mezclar cosas, yo separaría cada secreto por función:
| Credencial | Uso |
|---|---|
| Token temporal | Pruebas |
| Token de System User | Backend productivo |
| Verify token | Alta del webhook |
| App secret | Firma de eventos entrantes |
Además, dejaría estas reglas como piso:
En otras palabras: yo no pensaría esta auth como “mandar mensajes”, sino como un sistema de acceso, control y trazabilidad para que pedidos, envíos, soporte y ventas funcionen sin abrir puertas de más.
WhatsApp API para Tiendas: 4 Pasos de Autenticación y Control de Acceso
Antes de emitir tokens, tenés que dejar listos los activos base.
Antes de avanzar, necesitás cuatro activos: una cuenta de Meta Business Manager verificada, una WABA, un número dedicado y una app de Meta Developers con WhatsApp habilitado y los permisos whatsapp_business_messaging y whatsapp_business_management. Esos activos marcan qué puede autenticar la integración y con qué permisos.
Acá el orden no es un detalle. Importa mucho.
Primero, verificá el negocio en Meta. Eso incluye subir la documentación de la empresa, el CUIT y un comprobante de domicilio. Después, esperá la aprobación antes de pasar a producción.
Luego, creá la WABA dentro de esa cuenta de Meta Business Manager ya verificada, con un nombre alineado con la marca. Por ejemplo: "Tienda X Oficial".
Recién después sumás y verificás el número. Ese número tiene que estar libre y poder validarse por SMS o llamada. Una vez que lo conectás a la API, deja de poder usarse en WhatsApp personal o Business.
En Argentina, conviene chequear desde el inicio que el número tenga prefijo local +54 y que pueda recibir llamadas o SMS para la verificación inicial.
Antes de conectar nada, el equipo tiene que acordar qué datos toca esta integración. Los objetos centrales son clientes, pedidos, fulfillments, inventario, descuentos y políticas de la tienda.
No todo tiene el mismo nivel de riesgo. Leer el estado de un pedido, precios o políticas suele ser de bajo riesgo. En cambio, cambiar datos de contacto de un cliente, emitir reembolsos, modificar el valor de un descuento o tocar el stock ya entra en otra zona. Esas acciones tendrían que quedar bloqueadas para flujos automáticos o pedir una aprobación manual explícita.
Este mapeo define dos cosas:
Hay un punto que muchos pasan por alto: el campo de teléfono en el checkout tiene que ser obligatorio y guardar el código de país. Sin número, no hay automatización posible.
Ese mapa termina marcando el alcance mínimo que van a tener los tokens del sistema.
Si la tienda usa Burbuxa, hay un paso previo que no conviene saltear: definir quién hace la conexión.
En Burbuxa, la conexión queda atada a la persona que autoriza el acceso y a las tiendas que selecciona. Por eso, ese usuario tiene que tener permisos suficientes. Si no, más adelante aparecen trabas justo donde menos sirven.
Después de definir al dueño, toca confirmar el alcance de la sincronización: productos, pedidos, clientes, inventario, descuentos y políticas. Esa sincronización es la que permite que los flujos en WhatsApp trabajen con datos actuales de la tienda, sin depender de exportaciones manuales.
Con el dueño y el alcance ya definidos, podés pasar a usuarios del sistema y tokens.
Con los activos base ya preparados, ahora toca crear las credenciales que el backend va a usar en producción. Acá el orden no es un detalle menor: primero va el usuario del sistema, después se asignan los activos y recién al final se emite el token.
Entrá a business.facebook.com y seguí esta ruta: Business Settings → Users → System Users. Ahí creá un System User Admin. Un nombre claro ayuda bastante; por ejemplo, "WhatsApp-Tienda-Prod".
Cuando ese usuario ya exista, usá Assign Assets para vincularle la Meta App que usa WhatsApp Cloud API y también el WhatsApp Business Account (WABA). Si el número aparece como un activo aparte, asignalo también. La idea es simple: dejalo vinculado solo a los activos que va a usar en producción.
En permisos, conviene ir al grano:
whatsapp_business_messaging para mensajeríawhatsapp_business_management solo si el backend administra plantillas, números o el WABAbusiness_management y catalog_management únicamente si el flujo lo pideEsto tiene que respetar el mapa de lectura y escritura definido en el paso anterior.
No todas las credenciales sirven para lo mismo. Y si se mezclan, después aparecen errores raros, o peor, riesgos de acceso innecesario.
| Secreto/credencial | Vida útil | Dónde se usa | Quién la gestiona |
|---|---|---|---|
| Token temporal de desarrollo | Horas o días | Pruebas locales y sandbox | Desarrolladores |
| Token de System User | Largo plazo | Backend productivo | DevOps / Seguridad |
| Webhook verify token | Rotación manual | Verificación del callback | DevOps / Plataforma |
| App secret | Rotación manual | Firma y validación de webhooks | DevOps / Seguridad |
El token de System User se usa en Authorization: Bearer TOKEN y solo se puede copiar una vez al momento de generarlo. Si se pierde, no hay magia: hay que emitir otro.
El webhook verify token, en cambio, no da acceso a la API. Su única función es validar el callback URL. Son cosas distintas, aunque a veces se confundan en la práctica.
Con estos secretos ya definidos, el próximo paso es activar y validar los webhooks.
Guardá los secretos en un gestor con control de acceso y auditoría. No los pongas en repositorios, documentos compartidos ni chats. Las variables de entorno del servidor deberían leerlos desde ese gestor.
El acceso a secretos de producción tiene que quedar limitado a un grupo chico: idealmente, solo el runtime de la aplicación y los admins de plataforma. Desarrollo y soporte deberían interactuar con WhatsApp desde capas de más alto nivel, sin tocar credenciales crudas.
Para credenciales de alto privilegio, la rotación debería hacerse cada 30 a 90 días, y también de inmediato si aparece cualquier señal de compromiso. Cada cambio tiene que quedar registrado: quién lo hizo, qué cambió, cuándo y en qué entorno. El log no debería incluir el valor completo del token; alcanza con un identificador o hash para poder correlacionar eventos sin exponer el secreto.
Si usás Burbuxa, actualizá la automatización inteligente en WhatsApp al mismo tiempo que el backend y validá la conexión.
Con las credenciales listas, el siguiente paso es verificar el callback y suscribir los eventos necesarios.
Con las credenciales listas, ahora hay que validar cómo entra y sale WhatsApp antes de activar la mensajería en producción. En la práctica, esto significa dos cosas: que WhatsApp pueda enviar webhooks al backend de la tienda y que la tienda pueda responder con mensajes salientes según las políticas de Meta.
El callback URL tiene que ser un endpoint HTTPS, con certificado válido y accesible desde los servidores de Meta. Por ejemplo: https://api.mitienda.com/webhooks/whatsapp.
Cuando registrás el webhook, Meta envía un GET con hub.mode, hub.verify_token y hub.challenge. Tu servidor tiene que validar que hub.mode sea subscribe, comparar hub.verify_token con el valor guardado y devolver hub.challenge exacto en el cuerpo con HTTP 200. Si el token no coincide, corresponde devolver 403.
Después de esa verificación, empiezan a llegar las solicitudes POST. Cada una trae el encabezado X-Hub-Signature-256 con el formato sha256=<64 caracteres hex>. El servidor tiene que recalcular ese HMAC-SHA256 usando el App Secret, sobre el cuerpo crudo y antes de parsear el JSON, y luego compararlo con el encabezado usando una función de comparación de tiempo constante. Si no coincide, o si el encabezado no está, rechazá la solicitud y registrá el incidente.
Dicho simple: el verify token sirve para validar el callback, y el App Secret sirve para firmar y verificar cada evento entrante. Una vez validado el callback, ya podés recibir eventos firmados.
No hace falta suscribirse a todo. Conviene activar solo lo que la operación usa de verdad.
| Evento | Uso en la tienda | Qué no loguear |
|---|---|---|
messages | Cola de soporte y ventas | Solo metadatos mínimos |
Estados de mensaje (delivered, read, failed) | Confirmación de notificaciones de pedido, alertas de error y escalación | Contenido del mensaje; guardá solo ID y estado |
| Actualizaciones de conversación | Control de ventana de 24 horas y categoría | Metadatos innecesarios |
Si un estado failed aparece varias veces para el mismo número, marcá ese contacto como no alcanzable en el CRM y dejá de insistir. Seguir intentando no suma nada y solo mete ruido en la operación.
Con esos eventos activos, el próximo punto a controlar son las respuestas salientes fuera de la ventana de 24 horas.
Fuera de la ventana de atención de 24 horas, WhatsApp solo permite mensajes salientes con plantillas aprobadas, clasificadas como Utility, Marketing o Authentication.
Para una tienda argentina, el set mínimo de plantillas aprobadas suele incluir:
Todas deberían estar localizadas para Argentina. Eso incluye montos en ARS con punto para miles y coma para decimales, por ejemplo ARS 12.499,00, fechas en formato dd/mm/yyyy y palabras de uso local como "talle", "envío" y "promo".
Si Meta rechaza una plantilla, ajustá el texto, bajá el tono, corregí las variables a es-AR y volvé a enviarla. Mientras tanto, si tenés una ventana de 24 horas abierta con el cliente, podés responder con un mensaje libre. Si usás Burbuxa, la aprobación de plantillas y el opt-out quedan auditados.
Con mensajes y plantillas ya habilitados, el paso que sigue es definir quién puede usarlos y qué acciones necesitan aprobación.
Con la parte técnica de auth ya resuelta, queda una pieza igual de importante: definir quién puede hacer qué mediante flujos de trabajo personalizados y qué acciones no deberían correr sin revisión.
En esta etapa, credenciales, webhooks y permisos dejan de ser solo configuración. Pasan a ser reglas de trabajo para cada rol.
La idea es simple: no todo el mundo necesita el mismo nivel de acceso. Y, si todos pueden tocar todo, tarde o temprano algo se rompe.
| Capacidad | Admin técnico | Líder de soporte | Operador de ventas |
|---|---|---|---|
| Gestión de tokens y credenciales | Completa (crear, rotar y revocar) | Sin acceso | Sin acceso |
| Aprobación de plantillas | Configura y envía a Meta | Revisa plantillas | Usa solo plantillas aprobadas |
| automatización de flujos de conversación y acciones de riesgo | Configuración total | Aprobar excepciones | Solicitar aprobación |
| Acceso a conversaciones | Auditoría o debug | Acceso completo | Chats asignados |
| Escalamiento | Intervención de emergencia | Aprobar reembolsos y excepciones | Solicitar aprobación |
Una vez que esos límites están claros, el siguiente paso es marcar qué acciones necesitan una mirada humana antes de ejecutarse.
No todas las acciones en WhatsApp pesan lo mismo. Algunas son rutinarias. Otras pueden tocar plata, pedidos o la experiencia del cliente de forma directa. Ahí no conviene improvisar.
Estos casos deberían pasar por confirmación humana antes de ejecutarse:
Cuando un caso se deriva, el contexto completo tiene que ir con él. Eso incluye historial de mensajes con timestamps en formato dd/mm/aaaa HH:mm, ID de pedido, total en ARS y motivo de la derivación.
Y si la acción cambia datos - por ejemplo, un reembolso o un cambio de pedido - sumá un paso de preview y confirmación antes de ejecutar. También conviene usar claves de idempotencia para evitar transacciones duplicadas si hay reintentos de red. Es uno de esos detalles que parecen chicos hasta que aparece el primer cobro o reembolso repetido.
Antes del go-live, revisá solo lo que cambia en producción. Nada de asumir que, porque anduvo en staging, ya está.
También hace falta dejar por escrito el traspaso de responsabilidades. Ingeniería queda a cargo de tokens, webhooks y estabilidad del sistema. Soporte se ocupa de los flujos de postventa y las derivaciones. Ventas y marketing manejan las plantillas comerciales.
Si usás Burbuxa, confirmá responsables y alcance de sincronización antes de activar en producción.
Usar un token personal en producción trae un riesgo serio de seguridad y estabilidad. Por lo general, es estático y suele dar un nivel de acceso mucho más amplio que OAuth 2.0, que trabaja con tokens temporales y permisos más limitados.
Si ese token se filtra, puede seguir activo hasta que alguien lo revoque de forma manual. En ese lapso, podría dejar expuestos datos sensibles de tu tienda. Y hay otro problema: como está atado a un usuario, la auditoría se vuelve más engorrosa y el manejo de permisos también.
Aplicá el principio de menor privilegio: al System User dale solo los permisos que necesita para hacer su trabajo.
En lugar de darle acceso administrativo general, usá scopes puntuales según las tareas que vaya a ejecutar, como gestionar contactos o crear automatizaciones. También conviene revisar esos permisos cada tanto y sacar los accesos que ya no hagan falta.
Antes de llevar tu integración de WhatsApp API con Burbuxa a producción, hacé una revisión completa. La idea es simple: que todo funcione bien y que el acceso esté limitado a lo justo y necesario.
Probá primero en sandbox. Ahí podés detectar fallas sin tocar datos ni procesos en vivo. Después, chequeá que la sincronización en tiempo real de productos, pedidos y clientes esté funcionando como corresponde. Si alguno de esos datos se demora o se duplica, el problema después pega directo en la operación.
También conviene revisar los permisos. El sistema tiene que acceder solo a lo necesario, nada más. Menos acceso significa menos riesgo.
Además, prestá atención a estos puntos:
Dicho mal y pronto: una auditoría previa te puede ahorrar muchos dolores de cabeza cuando la integración empiece a mover datos de verdad.