Respuesta directa
Una plantilla de autenticación de WhatsApp debe ser aprobada antes de usarse en un mensaje empresarial con un código de un solo uso. Meta App Review es una revisión distinta de los permisos y el modelo de acceso de la aplicación, sobre todo cuando el software gestiona activos de WhatsApp o envía mensajes para empresas clientes. Crear la plantilla no demuestra por sí solo que App Review sea necesario o esté aprobado.
Haz dos preguntas. ¿Cumple la plantilla las reglas de autenticación? ¿Tiene la aplicación de Meta los permisos para las empresas y los activos que operará? Superar una revisión no sustituye la otra.
Entiende las dos rutas de aprobación
La aprobación de plantillas revisa un mensaje concreto. La política de mensajería de WhatsApp Business exige una plantilla aprobada para iniciar una conversación y permite que WhatsApp la revise, apruebe, pause o rechace.
App Review revisa el uso de permisos. Una empresa que envía para su propia cuenta de WhatsApp Business y un proveedor tecnológico que trabaja para clientes no siempre siguen la misma ruta. Los requisitos dependen del modelo, el nivel de acceso y los activos.
El estado APPROVED de una plantilla no demuestra Advanced Access para la aplicación. Un permiso aprobado tampoco garantiza la aprobación de todas las plantillas futuras.
Decide cuándo se aplica App Review
Usa el panel de desarrolladores de Meta como fuente principal para la aplicación que controlas. Anota cada permiso, su nivel de acceso, quién posee las cuentas de WhatsApp Business y qué acción ejecuta la aplicación.
Para un proveedor tecnológico, la evidencia suele separar dos acciones. La evidencia de messaging muestra el envío desde la aplicación y la llegada a una interfaz real de WhatsApp. La evidencia de management muestra la creación o gestión de una plantilla. La guía de integración de Twilio documenta esta separación en su proceso.
Graba una demostración clara con datos de prueba y un solo objetivo de permiso cada vez. No muestres tokens, datos de clientes ni identificadores privados.
Crea correctamente la plantilla
Las plantillas de autenticación sirven para códigos de inicio de sesión, registro o recuperación. Mantén el mensaje limitado a la verificación. No conviertas la categoría authentication en publicidad ni añadas una acción comercial.
La colección oficial de plantillas de Meta muestra la creación en el punto message templates de una cuenta de WhatsApp Business con la categoría AUTHENTICATION. Sus ejemplos incluyen recomendación de seguridad, aviso de vencimiento y botón OTP.
Usa un nombre estable y una versión para cada idioma real. El aviso de vencimiento informa al cliente, pero no invalida el código en tu servidor. El servicio de autenticación debe imponer por separado la caducidad y el uso único.
Elige copiar código o un toque
Una plantilla de copia ofrece un botón que copia el código. El ejemplo de Meta para copiar usa un botón OTP de tipo COPY_CODE. Es la opción más simple para una ruta amplia de dispositivos o cuando no controlas una aplicación Android.
Una plantilla de un toque puede pasar el código a una aplicación Android coincidente después del toque. El ejemplo de Meta para un toque incluye el package name y el signing hash. Usa los datos de producción y no los de depuración. Conserva la copia como ruta alternativa cuando la aplicación no coincide.
Elige desde la experiencia del cliente. Copiar de forma fiable es mejor que el llenado automático que solo funciona en el teléfono de prueba.
Crea y envía la plantilla
- Confirma la cuenta de WhatsApp Business y el número que serán propietarios.
- Elige AUTHENTICATION y un uso de inicio de sesión, registro o recuperación.
- Elige copia o un toque según la experiencia compatible.
- Añade solo los componentes de seguridad y vencimiento que puedes aplicar.
- Prepara cada idioma con redacción natural.
- Envía la plantilla y guarda identificador, categoría y estado.
- No uses tráfico de producción antes de la aprobación del idioma exacto.
En las plantillas de DripTell, mantén el nombre, idioma y propósito alineados con el flujo que envía. La aprobación es una puerta de entrada, no una prueba de entrega o verificación.
Prueba toda la verificación
Prueba por separado la aprobación, la entrega y el resultado del código. Usa destinatarios de prueba y códigos no productivos. Comprueba éxito, demora, vencimiento, reutilización, error, falta de llenado, copia alternativa y demasiados intentos.
La aceptación por la API de envío solo indica que la solicitud entró en la plataforma. No prueba que llegó a la persona ni que completó la autenticación. Concilia los estados con tu resultado sin guardar el código en analítica o notas.
Si el cliente necesita ayuda, dirige la conversación a una bandeja compartida sin mostrar el código. El agente debe verificar la identidad mediante el proceso aprobado y nunca pedir que se lea un código de un solo uso en voz alta.
Evita causas comunes de rechazo
- La categoría no coincide con el propósito.
- El texto incluye marketing o una acción ajena.
- El idioma enviado no coincide con el mensaje.
- Las variables y ejemplos no muestran autenticación real.
- Un toque usa un package o signing hash incorrectos.
- El vídeo de App Review no muestra el permiso solicitado dentro de la aplicación.
- La grabación revela secretos o datos de clientes.
- Producción trata la aceptación de la API como verificación completada.
Tras un rechazo, lee el motivo, cambia el elemento mínimo relevante y documenta la nueva versión. No reenvíes una plantilla sin cambios repetidamente.
Controla acceso y evidencia
Concede gestión y envío solo a los roles necesarios. Separa prueba y producción y conserva un registro de cambios. La seguridad de DripTell puede apoyar la separación de roles y espacios, pero la aprobación de Meta y la seguridad de autenticación siguen siendo responsabilidad del propietario.
La regla práctica es sencilla. Demuestra que la plantilla está permitida, que la aplicación puede ejecutar la acción y que el cliente completó la verificación. Son tres hechos distintos y deben medirse por separado.
Preguntas frecuentes
¿Todas las plantillas necesitan App Review?
Cada plantilla necesita aprobación. App Review depende de los permisos, el nivel de acceso y si la aplicación opera activos propios o de empresas clientes.
¿Una plantilla aprobada demuestra que el código se entrega?
No. La aprobación permite usarla. Debes probar entrega, vencimiento, uso único, alternativa y resultado final.
¿Funciona un toque sin package name y signing hash?
El ejemplo oficial de Meta exige ambos. Si no coinciden con la aplicación de producción instalada, usa la copia y corrige la configuración.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes