Guía práctica · PotencIA · WhatsApp y CRM

Cómo integrar WhatsApp Cloud API con un CRM paso a paso

Los trece pasos para conectar WhatsApp Cloud API con un CRM: alta en Meta, webhooks, identificación del contacto, IA, citas y paso a persona.

Erick José Piñerua JiménezPublicado el
Un desarrollador trabaja con dos pantallas en la mesa de una oficina pequeña, con una libreta de notas abierta al lado del teclado.

Integrar WhatsApp Cloud API con un CRM son trece pasos, y solo los cinco primeros son configuración en Meta: el resto es software que alguien tiene que escribir y mantener. Esa proporción es la que casi nunca se explica, y es la que decide si el proyecto sale adelante o se queda a medias.

Debajo está el recorrido completo, en el orden real en que se hace, con lo que se decide en cada punto. No hay credenciales ni claves en este texto, y no debería haberlas en ninguno: son secretos de servidor.

El recorrido de un mensaje, de un vistazo

Antes de los pasos, conviene tener el mapa en la cabeza. Un mensaje entrante hace este camino:

  1. WhatsApp — el cliente escribe desde su móvil.
  2. WhatsApp Cloud API — Meta recibe el mensaje en su infraestructura.
  3. Webhook — Meta llama a una dirección de tu servidor con los datos.
  4. Backend — tu sistema valida la llamada y la procesa.
  5. CRM — se identifica o se crea el contacto y se guarda el mensaje.
  6. IA y automatización — se decide qué responder o qué acción ejecutar.
  7. Respuesta por WhatsApp — sale de vuelta por la misma vía.

Todo eso ocurre en unos segundos. Los pasos que siguen son cómo se construye cada tramo.

Primero: la configuración en Meta

1. Crear el entorno en Meta

Hace falta una cuenta de empresa en Meta y una aplicación dentro de ella con el producto de WhatsApp añadido. La aplicación es el objeto que tendrá permiso para actuar sobre el número.

Los requisitos previos de alta —verificación del negocio, número disponible y perfil de empresa— están detallados en la API oficial de WhatsApp, y aquí se dan por hechos. Conviene tener desde el principio dos entornos separados, uno de pruebas y otro real. Probar contra el número que atiende a clientes es una mala idea que solo se comete una vez.

2. La cuenta de WhatsApp Business

Es el contenedor que agrupa el número, las plantillas y las estadísticas. Meta la describe como la cuenta que «representa a tu empresa y contiene números de teléfono, nombres de usuario y estadísticas» (traducción nuestra).

Aquí se decide algo que importa más de lo que parece: a nombre de quién queda esa cuenta. Si la crea tu proveedor dentro de su propia estructura, migrar después es un problema. Pregúntalo por escrito antes de empezar.

3. El número de teléfono

Tiene que poder recibir una verificación y no estar activo en la aplicación de WhatsApp. Al darlo de alta, Meta le asigna un identificador interno: ese identificador, y no el número, es el que usará tu código.

También se configura aquí el nombre visible del negocio, que Meta revisa y puede rechazar si no corresponde con la empresa real.

4. Credenciales y permisos

La aplicación obtiene un token de acceso con el que autoriza cada petición. Tres reglas que no son negociables:

  • Nunca en el código fuente. Ni en el repositorio, ni en el frontend, ni en una captura de pantalla.
  • Solo en variables de entorno del servidor, cifradas si se guardan en base de datos.
  • Rotables. Tiene que ser posible cambiarlas sin reescribir nada.

Un token de producción filtrado permite escribir a tus clientes en tu nombre. No es un detalle menor.

5. El webhook

Se declara una dirección pública de tu servidor donde Meta enviará las notificaciones. La verificación inicial es un intercambio sencillo: Meta llama con un valor que tú has configurado y espera que le devuelvas el desafío que te manda. Si coincide, queda suscrito.

A partir de ahí hay una comprobación que no se puede saltar: cada llamada llega firmada, y el servidor debe verificar esa firma antes de procesar nada. Sin esa verificación, tu dirección acepta mensajes de cualquiera que la conozca.

Después: el software

6. Recibir el mensaje

La documentación de Meta describe qué llega: los webhooks «entregan cargas JSON a tu servidor para actualizaciones de estado de mensajes, mensajes entrantes y gestión asíncrona de errores» (traducción nuestra).

Dos cosas que se aprenden a base de disgustos:

  • Responde rápido y procesa después. Si tu servidor tarda, Meta reintenta y acabas con mensajes duplicados. Lo correcto es confirmar la recepción y encolar el trabajo.
  • El mismo mensaje puede llegar dos veces. Guarda el identificador de mensaje y descarta lo repetido. Sin esto, un reintento produce dos respuestas al cliente.

7. Identificar al contacto

El mensaje trae el número de quien escribe. Con él se busca en el CRM:

  • Si existe, la conversación se engancha a su ficha con todo su historial.
  • Si no existe, se crea el contacto.

Aquí está el fallo más común de toda la integración: normalizar mal el número. El mismo teléfono puede llegar con prefijo, sin él, con ceros delante o con espacios. Si no se normaliza a un formato único antes de buscar, se crean fichas duplicadas del mismo cliente y el historial se parte en dos.

8. Crear o actualizar el cliente

Lo que conviene guardar en cada mensaje entrante: quién escribe, qué dijo, cuándo, por qué canal y a qué conversación pertenece. Y en la ficha, si es nuevo o recurrente.

Una decisión de diseño que se agradece meses después: guardar el mensaje tal como llegó, sin procesar, además de la versión interpretada. Cuando algo salga raro, es la única forma de reconstruir qué pasó.

9. Responder

La respuesta sale haciendo una petición al servicio de Meta con el identificador del número y el contenido. Meta devuelve un identificador de mensaje que sirve para seguir su estado de entrega.

Lo que condiciona qué puedes enviar es la ventana de 24 horas: dentro, texto libre; fuera, solo plantillas aprobadas previamente. Toda la lógica de recordatorios depende de esa distinción.

10. La capa de IA

Va después de identificar al contacto, nunca antes. El orden importa porque el asistente debería responder sabiendo quién pregunta.

Lo que necesita para funcionar:

  • La información del negocio: servicios, horarios, precios, preguntas frecuentes. Y alguien que la mantenga cuando cambie.
  • El historial de esa conversación, para no preguntar lo que ya le dijeron.
  • Un límite escrito de qué puede decidir sola y qué debe derivar.
  • Una salida para lo que no sabe. Un asistente que improvisa cuando no tiene el dato es peor que uno que dice que va a preguntar.

11. Registrar la conversación

Cada intercambio se guarda asociado al contacto, con quién respondió —IA o persona— y en qué estado quedó. Ese registro es lo que después permite medir y hacer seguimiento.

12. Gestionar citas

Si el asistente reserva, tiene que hacerlo contra la disponibilidad real, no contra un horario teórico. La regla que no debería saltarse ningún sistema:

Primero se crea la cita. Después se confirma al cliente. Nunca al revés.

Un asistente que confirma antes de escribir en la agenda produce citas fantasma: el cliente cree que tiene hora y en el calendario no hay nada. Es el fallo más caro de todos, porque el negocio se entera cuando el cliente se presenta.

13. El paso a una persona

El último tramo, y el que más se descuida:

  • La persona que entra ve todo lo hablado.
  • La IA deja de responder en ese hilo mientras haya alguien.
  • Queda registrado quién tomó la conversación y cuándo.
  • Hay un aviso, porque una derivación que nadie ve no es una derivación.

Lo que hay que mantener después

El proyecto no termina el día que funciona:

  • Los tokens caducan o se rotan. Si no hay aviso, te enteras por un cliente.
  • Las plantillas se aprueban y también se rechazan. Un cambio de texto vuelve a pasar revisión.
  • La calificación de calidad del número se mueve. Si baja, bajan tus límites de envío.
  • Meta cambia versiones de su interfaz. Las versiones antiguas dejan de estar disponibles con el tiempo.
  • La información del negocio envejece. Es el mantenimiento que más valor aporta y el que nadie presupuesta.

No necesitas desarrollar toda esta infraestructura desde cero

Los trece pasos de arriba son un proyecto de software con mantenimiento continuo. Tiene sentido hacerlo si tu negocio es el software, o si tienes requisitos tan específicos que ninguna herramienta los cubre.

Para el resto de los casos, existe la alternativa de usar una plataforma que ya tenga hecha esa parte. Es lo que hacemos nosotros: PotencIA funciona sobre esta misma vía oficial de Meta, con el CRM, la agenda, el asistente y el paso a persona ya montados. Lo que se configura no es la infraestructura, sino la información del negocio y las reglas de qué responde sola la IA y qué no.

Qué incluye exactamente está en el CRM con WhatsApp integrado, y el producto completo en la página de PotencIA.

Preguntas relacionadas

¿Cuánto tarda una integración así?

La parte de Meta —verificar el negocio y dar de alta el número— puede ir de unas horas a varios días y no depende de ti. El software de los pasos 6 a 13, hecho con criterio y con pruebas, son semanas, no tardes. Y el mantenimiento no se acaba.

¿Necesito un servidor propio?

Necesitas una dirección pública accesible por Meta para el webhook, con certificado válido. Puede ser un servidor propio o un servicio gestionado; lo que no puede es estar en tu portátil.

¿Y si la verificación del negocio va a tardar?

Hay negocios que arrancan con una conexión por código QR mientras esperan, y migran después. Es una decisión con ventajas e inconvenientes reales, comparados en API oficial o conexión por QR.

¿Puedo probar sin dar de alta mi número real?

Sí, y conviene. Meta permite trabajar con un número de pruebas asociado a la aplicación, con destinatarios limitados. Es donde hay que equivocarse.

¿Qué pasa si mi servidor se cae?

Meta reintenta la entrega de los webhooks durante un tiempo, así que una caída corta no pierde mensajes. Una caída larga sí. Conviene tener aviso de que el webhook ha dejado de recibir llamadas: es la señal más temprana de que algo se rompió.

Fuentes consultadas

El orden de los trece pasos, la regla de crear la cita antes de confirmarla y los fallos frecuentes de normalización de números son criterio propio de PotencIA, sacado de montar esta integración. Este artículo lo firma una parte interesada.