Definición en una frase
Un Business-Scoped User ID (BSUID) es un identificador único que Meta asigna a cada usuario de WhatsApp dentro del ámbito de un negocio concreto. Su formato es XX.<dígitos> (por ejemplo, 45.78492611). Llega en el webhook de WhatsApp Business Platform cuando el cliente escribe usando su username y no comparte el número de teléfono.
A partir de ahí, los matices.
Formato exacto y ejemplo real
El BSUID es un string con esta estructura:
45.78492611
13.7849263
71.20183442
Dos cifras al principio, un punto, y a continuación una cadena larga de dígitos. La parte inicial no es el prefijo internacional del país: es un componente interno del identificador. Para validarlo en código vale una expresión regular sencilla:
const BSUID_REGEX = /^\d{2}\.\d+$/;
Importante: se trata como string, nunca como número. Si lo guardas como número pierdes los posibles ceros a la izquierda y el punto deja de tener sentido como separador.
Diferencia con el número de teléfono y con el WhatsApp ID
Tres identificadores conviven en la API de WhatsApp Business:
- Teléfono internacional (
+34 600 000 000): el de toda la vida. Visible cuando el cliente lo comparte explícitamente o cuando hay interacción reciente con tu cuenta. - WhatsApp ID o wa_id (
34600000000): formato sin signos, sin espacios. Lo usa Meta como identificador estable global del cliente cuando el teléfono está disponible. - BSUID (
45.78492611): el nuevo, sustituye al wa_id en los casos en que el cliente escribe usando su username sin compartir teléfono.
La diferencia conceptual que más confunde es esta: el teléfono y el wa_id eran identificadores globales del cliente (el mismo cliente, mismo wa_id en todos los negocios). El BSUID es un identificador local al negocio: el mismo cliente tiene BSUIDs distintos en cada negocio con el que conversa.
Por qué Meta lo llama "scoped" (alcance por negocio)
El nombre completo, Business-Scoped User ID, es una descripción técnica de lo que hace. Cada cliente, en cada negocio, recibe su propio BSUID. Tres negocios distintos = tres BSUIDs distintos del mismo cliente. Y, dentro de un mismo grupo empresarial, cada cuenta business también es un scope distinto: si tu grupo tiene cinco restaurantes con cinco cuentas business separadas, la misma clienta genera cinco BSUIDs.
Esta decisión de diseño es deliberada de Meta y responde a una lógica de privacidad: ningún negocio puede cruzar BSUIDs con otro para deducir que un cliente es el mismo. La consecuencia operativa para grupos empresariales es que la unificación de identidad entre sedes no la puede hacer WhatsApp; la tiene que hacer tu CRM.
Cuándo recibes el BSUID en el webhook
Cuando un cliente que ha activado su username escribe a tu cuenta business y no se cumple ninguna de estas condiciones:
- El cliente ha tenido conversación contigo en los últimos 30 días.
- Tu cuenta business tiene su número de teléfono guardado en agenda.
Si una de las dos se cumple, sigues viendo el teléfono. Si ninguna se cumple, lo que recibes en el webhook es el BSUID, sin teléfono asociado.
Llega como campo dentro del payload de mensaje entrante de WhatsApp Business API. Tu integración tiene que leerlo, normalizarlo como string y mandarlo al CRM para la creación o actualización de ficha.
Cinco errores comunes al guardar el BSUID en el CRM
Por orden de frecuencia esperada en los próximos meses:
- Tratarlo como número y perder el formato. Si lo guardas como integer o float, el punto desaparece y los ceros a la izquierda también. Siempre string.
- Usarlo como clave primaria del cliente. Es un identificador estable, pero es por negocio. Si el cliente resetea o cambia número, puede cambiar. Mejor como atributo identificador en una ficha con clave primaria interna del CRM.
- No reconocer que el mismo cliente tiene BSUIDs distintos entre sedes del grupo. Es la causa de que un cliente VIP aparezca como cinco fichas distintas en grupos con varias cuentas business. Esto se trata en detalle en la guía completa de BSUID para restaurantes.
- Asumir que reemplaza al teléfono. No lo hace. Coexisten. Tu ficha cliente debería aceptar ambos campos como paralelos.
- No guardar timestamp de creación del BSUID. Si en algún momento el cliente resetea y aparece un BSUID nuevo, sin timestamp del antiguo no puedes auditar la transición. Para grupos con auditoría operativa exigente, conviene guardar el histórico de BSUIDs por ficha, no solo el actual.
Cómo se guarda bien en el CRM
En una frase: como un identificador más, no como el identificador.
La ficha cliente acepta varios identificadores opcionales (teléfono, BSUID, email, externo del PMS), con clave primaria interna del CRM. La lógica de deduplicación cruza los disponibles. La regla de match por BSUID solo se aplica dentro del mismo scope, es decir, dentro de la misma cuenta business. Para fusionar identidad del mismo cliente entre cuentas business distintas del grupo, el match se hace por teléfono histórico, email o pistas de la conversación, nunca por BSUID.
Si tu equipo técnico está rediseñando el schema para esto, el diseño que funciona es: tabla customer con clave interna + tabla customer_identifier con (customer_id, type, value, business_scope_id, valid_from, valid_to). Con eso tienes histórico, multi-scope y futuras migraciones cubiertas.