Conecta WhatsApp con Bitrix24 CRM en un número con Coexistencia

¿Cómo habla n8n con Bitrix24?

Mediante un webhook entrante, que en Bitrix24 no es un receptor sino una credencial. Lo creas en los recursos para desarrolladores de Bitrix24, eliges los permisos que puede usar y obtienes una URL con la dirección de tu portal, el id del usuario que lo creó y un código secreto. Al añadir el nombre de un método a esa URL se llama a la API REST como ese usuario, con sus permisos.

Así, en n8n cada paso de Bitrix24 es un nodo HTTP Request que hace POST a esa URL más un método como crm.lead.add.json. No hay flujo OAuth que completar ni app que publicar. Dale al webhook solo el permiso de CRM y créalo con un usuario cuyos permisos cubran los leads y contactos que el flujo debe ver, ya que Bitrix24 comprueba el acceso como ese usuario.

¿Qué métodos de Bitrix24 llama el flujo?

Tres, en orden, después de que el nodo Webhook de n8n reciba el mensaje de Meta.

crm.duplicate.findbycomm con el tipo PHONE y el número del remitente devuelve los ids de los leads, contactos y empresas que lo tienen. Es la búsqueda adecuada porque consulta los tres a la vez y está pensada para comparar comunicaciones, no un campo de texto.

Cuando no devuelve nada, crm.lead.add crea un lead con el nombre del perfil de WhatsApp como título y el número en su campo de teléfono. Después crm.timeline.comment.add escribe el texto del mensaje como comentario del registro, con ENTITY_TYPE, ENTITY_ID y COMMENT. El comentario aparece en la cronología del registro junto a las llamadas y los correos, donde un vendedor ya mira.

POST https://yourcompany.bitrix24.com/rest/1/<secret>/crm.duplicate.findbycomm.json
{ "type": "PHONE", "values": ["14155550188"] }

POST .../crm.lead.add.json
{ "fields": { "TITLE": "WhatsApp: Maria", "PHONE": [{ "VALUE": "14155550188", "VALUE_TYPE": "MOBILE" }] } }

POST .../crm.timeline.comment.add.json
{ "fields": { "ENTITY_TYPE": "lead", "ENTITY_ID": 4211, "COMMENT": "do you have anything friday?" } }

¿Cómo condiciona el límite de tasa al flujo?

Bitrix24 mide las llamadas REST con un cubo con fugas. Cada petición suma al contador, el contador baja a un ritmo fijo por segundo y, cuando supera un umbral, la siguiente petición recibe un 503 con QUERY_LIMIT_EXCEEDED. En los planes Enterprise el contador baja 5 por segundo con un umbral de 250; en todos los demás baja 2 con un umbral de 50.

Cada mensaje entrante cuesta dos o tres llamadas, así que un goteo constante nunca se acerca. Una ráfaga sí: cincuenta clientes que respondan a la misma plantilla en un minuto son hasta 150 llamadas. Configura los nodos HTTP Request para reintentar al fallar con una espera corta y ejecuta las ejecuciones del flujo de una en una, de modo que la ráfaga se vaya vaciando hacia Bitrix24 en lugar de rebotar.

¿Las respuestas escritas en el teléfono llegan a Bitrix24?

Pueden llegar. En un número con Coexistencia la app de WhatsApp Business sigue funcionando y, cuando alguien responde desde ella, Meta envía un eco del mensaje saliente al mismo destino del webhook, en el campo smb_message_echoes.

Una segunda rama del flujo trata esos ecos igual que los mensajes entrantes, con el comentario marcado como saliente. El registro muestra entonces la conversación completa, con las líneas del cliente y las respuestas del negocio en orden.

Las respuestas que envía el propio flujo a través de la Cloud API ya están en manos del flujo cuando salen, así que regístralas en ese momento en lugar de esperar a que vuelva un webhook.

Errores comunes

• Pegar la URL del webhook entrante en código del lado del cliente o en un documento compartido. El secreto que contiene concede todos los permisos que se dieron al webhook.
• Crear el webhook con un usuario que no ve todos los leads. Las búsquedas fallan y el flujo crea duplicados.
• Enviar una ráfaga de llamadas sin reintentos. Bitrix24 responde 503 QUERY_LIMIT_EXCEEDED y esos mensajes nunca llegan a la cronología.

Preguntas frecuentes

Sigue leyendo