Dos números de WhatsApp en un mismo CRM: qué se rompe

La petición llega siempre igual: "tenemos un número para ventas y otro para soporte, y queremos los dos en el mismo CRM". Suena a configuración de cinco minutos. Casi nunca lo es, y el motivo no es capricho de nadie: es cómo están hechas las dos piezas.

La restricción de Meta

Una cuenta de WhatsApp admite una sola dirección de webhook. Una. Eso significa que dos servicios distintos no pueden suscribirse al mismo número para recibir sus mensajes: el segundo que se registre desplaza al primero.

Cuando un negocio quiere que el mismo número alimente a la vez el CRM y un bot que conversa, ahí está el conflicto. Elegir uno es perder algo: sin el puente al CRM no queda registro de la conversación; sin el bot no contesta nadie.

Nos pasó con nuestro propio número. Durante un tiempo tuvo dos servicios disputándoselo: uno recibía y escribía la conversación en el CRM, y el otro —el que califica y agenda— no veía un solo mensaje. Su log no movía una línea y parecía que estuviera roto. No estaba roto: no le llegaba nada.

El fallo silencioso del lado del CRM

El segundo problema es más traicionero, porque no involucra a Meta.

Muchos puentes que conectan WhatsApp con un CRM guardan sus registros indexados por la sub-cuenta del CRM, no por el número de teléfono. El nuestro lo hace así, y por buenas razones: es lo que permite que un solo servicio atienda a varios clientes.

La consecuencia es la que nadie anticipa. Dar de alta un segundo número sobre la misma sub-cuenta no da error ni conflicto. Pisa el registro que estaba, y el número anterior se queda sin nadie que lo atienda.

Hay una protección, pero cuida el caso contrario: impide asignar un teléfono que ya pertenece a otro registro. Que dos teléfonos se peleen la misma sub-cuenta no lo vigila nadie, porque el segundo simplemente reemplaza al primero.

En agosto estuvo a punto de mordernos. Íbamos a conectar un número personal sobre una sub-cuenta que ya era de un bot captador. Eso habría dejado mudo al bot sin un solo mensaje de error. La sub-cuenta correcta era otra, que además ya tenía ese teléfono en su ficha.

Y así es como se ve el daño: el síntoma sería "el bot dejó de responder" en un cliente distinto al que se acababa de tocar, días después, y sin nada en los registros que relacione una cosa con la otra.

La solución que sí funciona

Para el caso de dos servicios sobre un mismo número, la salida es que uno reciba y le pase una copia al otro.

El puente recibe el webhook de Meta, escribe en el CRM como siempre, y manda una copia al servicio del cliente. Tres decisiones de esa copia importan y no son obvias:

Va el cuerpo crudo y la firma original. El destino verifica la firma con el mismo secreto de la aplicación de Meta. Si se re-serializa el JSON cambia un byte y la firma deja de coincidir.

No se espera la respuesta, y no cuenta para el acuse a Meta. Si contara, un bot caído haría que Meta reintentara el webhook completo, y como el CRM no deduplica, el mensaje quedaría duplicado en la conversación del cliente. Quien garantiza la entrega es la escritura en el CRM, no la copia.

El destino tiene que deduplicar por identificador de mensaje. Un reintento de Meta llega dos veces, y cualquier servicio que se enganche ahí tiene que estar preparado.

La alternativa que parece más simple —apuntar el webhook de la cuenta directamente al bot y que el bot reenvíe al puente— es peor. Esa dirección queda grabada en cada cuenta que se conecte, y pone al bot en el camino crítico de la escritura en el CRM de todos los clientes.

Para dos números de verdad distintos

Si son dos números reales —ventas y soporte, o dos sedes— la regla que sacamos es simple:

Un número nuevo de un cliente que ya está = sub-cuenta nueva, no una segunda fila en la misma. Si el negocio necesita los dos números conviviendo dentro de un solo CRM, eso hay que decidirlo antes de montar nada, no descubrirlo después.

Antes de conectar cualquier número, la comprobación es una sola pregunta: ¿esta sub-cuenta ya tiene un número asignado? Diez segundos de consulta contra días de un bot mudo en otro cliente.

La lista antes de conectar un segundo número

1. ¿La sub-cuenta destino ya tiene un número? Si lo tiene, no agregues: decide.
2. ¿Los dos números tienen que verse en el mismo tablero, o basta con dos espacios separados?
3. Si dos servicios necesitan el mismo número, monta la copia del webhook — no repuntes la dirección de la cuenta.
4. Verifica por efecto, no por respuesta: manda un mensaje real a cada número y comprueba que llegó a donde debía.

Esto último vale para todo lo que toque webhooks. Escribimos aparte por qué un 200 no prueba que tu integración funciona.

Y si prefieres que la arquitectura la decida alguien que ya se estrelló con esto, así montamos WhatsApp sobre un CRM.