BSUID y Usernames en WhatsApp: El mayor cambio en la API de Meta en años

Hay un cambio silencioso ocurriendo en las entrañas de la API de WhatsApp. No aparece en el registro de cambios (changelog) como un cambio disruptivo (breaking change). No va a tirar abajo tu integración de la noche a la mañana. Pero va a hacer que, gradualmente a lo largo de 2026, quede obsoleta la suposición que toda plataforma de atención, todo CRM y todo bot construido en los últimos años asume como verdad fundamental: el cliente es su número de teléfono.

Este cambio tiene nombre: BSUID Business-Scoped User ID. Y viene acompañado de una función que WhatsApp nunca había tenido y que lo hace, finalmente, más parecido a Instagram y Telegram: usernames (nombres de usuario).

¿Qué son los Usernames de WhatsApp?

En junio de 2026, Meta comenzará a liberar para usuarios de países seleccionadosincluyendo Brasilla posibilidad de crear un nombre de usuario único en WhatsApp. Piensa en algo como @juansilva o @mariaolivera. La diferencia con el número de teléfono es radical: el username es elegido por el usuario, es público por defecto, y permite que alguien inicie una conversación con una empresa sin revelar nunca su número.

Esto no es un cambio cosmético. Para el ecosistema de atención al cliente, representa una inversión en el flujo de información. Hoy en día, cuando un cliente envía un mensaje a tu WhatsApp Business, recibes automáticamente su número de teléfono. Con los usernames, si ese cliente ha adoptado un @handle, puedes recibir únicamente el nuevo identificador, sin el +55 11 9xxxx-xxxx.

En algunos aspectos, el modelo se aproxima al correo electrónico: puedes conocer la dirección de la persona sin conocer su número de celular. Pero hay una diferencia importante que veremos a continuación: este identificador no es portable entre empresas.

Pantalla inicial de Android con búsqueda Google — los identificadores en WhatsApp evolucionan más allá del número; el móvil sigue siendo la puerta de entrada

¿Qué es el BSUID?

El BSUID (Business-Scoped User ID) es el identificador que Meta crea automáticamente para cada par único de usuario + portafolio de negocios. En otras palabras: para cada uno de tus clientes en WhatsApp, existe un BSUID generado específicamente para tu empresa.

El formato está estandarizado: un prefijo de dos caracteres con el código ISO del país, un punto, y una secuencia alfanumérica de hasta 128 caracteres. Por ejemplo: BR.13491208655302741918. Simple en apariencia, pero con implicaciones profundas en la arquitectura de datos.

La propiedad más importante del BSUID es justamente la que lo hace "scoped" (acotado al negocio): el mismo usuario tiene BSUIDs diferentes para cada empresa. El Juan Silva que conversa con tu empresa y con un competidor tiene un BSUID contigo y otro completamente diferente con el competidor. Esto es intencional y protege la privacidad del usuario; ninguna empresa puede rastrear el comportamiento del cliente en otras empresas a partir de este identificador.

A partir del 31 de marzo de 2026, el BSUID ya comenzará a aparecer en los webhooks de la API, independientemente de si el usuario ha adoptado un username o no. Esto es importante: todos tus clientes ya tienen un BSUID generándose, solo necesitas comenzar a capturarlo.

¿Por Qué es un Cambio Estructural?

Para entender la magnitud, piensa en cómo se construyeron la mayoría de los sistemas de CRM y atención. El campo wa_idel identificador de WhatsAppsiempre ha sido el número de teléfono. Era simple, conveniente y universal: el mismo número que guardabas en el registro del cliente era el mismo que llegaba en el webhook.

Esta convención duró más de una década. Todo esquema de base de datos, toda lógica de deduplicación, toda automatización de marketing, todo bot y toda integración con ERP se construyó bajo esa premisa. El teléfono era simultáneamente el canal de contacto, el identificador del sistema y el dato de CRM.

El BSUID rompe esta equivalencia. A partir de ahora, el identificador del sistema (user_id en el webhook) puede existir sin el número de teléfono. Y cuantos más usuarios adopten usernames, mayor será la proporción de conversaciones donde el wa_id (teléfono) estará ausente u omitido.

No es una exageración decir que esto exige una revisión arquitectónica en toda plataforma de atención que no se prepare. La buena noticia es que la transición es gradual. La mala noticia es que los sistemas que no se adapten no explotarán, sino que perderán conversaciones silenciosamente.

El Riesgo Real: Silencio Operacional

Un término circula entre los especialistas en la API de Meta para describir lo que les sucede a los sistemas no preparados: "Operational Silence" (silencio operacional). El sistema parece funcionar. El panel de control no muestra errores. Pero parte de las conversaciones simplemente no llegan.

Esto sucede en dos flujos específicos. Primero, en los anuncios Click-to-WhatsApp: cuando un usuario con username hace clic en el anuncio e inicia una conversación, el sistema espera un wa_id que sea un número de teléfono, no lo encuentra, y genera un registro duplicado o descarta la interacción. Segundo, en los mensajes de servicio inbound: los usuarios con username que escriben a tu número no son reconocidos por la deduplicación y pueden terminar como clientes "nuevos" en el sistema, perdiendo todo el historial.

El peor escenario no es que el sistema falle (ya que verías el error y lo solucionarías). El peor escenario es que el sistema acepte el mensaje, cree un registro duplicado y el agente atienda al "nuevo cliente" sin saber que se trata de alguien con 5 años de historial de compras.

El Contact Book: La Protección que Ofrece Meta

Para mitigar la ruptura, Meta introdujo en abril de 2026 una funcionalidad llamada Contact Book (Libro de Contactos) a nivel de WABA que almacena automáticamente los pares número de teléfono ↔ BSUID de todas las interacciones anteriores.

El Contact Book funciona así: siempre que un cliente que ya haya conversado con tu empresa adopte un username, Meta mantiene la asociación entre su BSUID y el número de teléfono que ya conoces. Durante 30 días después de una interacción, el número del cliente sigue apareciendo en los webhooks incluso si ha adoptado un username.

Esto significa que tu base de clientes existente está protegida durante la transición, al menos por un período. El problema surge con los clientes nuevos que adopten un username antes de haber entrado en contacto con tu empresa por primera vez. Para ellos, recibirás únicamente el BSUID, sin teléfono.

La buena noticia es que el Contact Book está habilitado por defecto. No necesitas hacer nada para activarlo. Pero debes empezar a capturar el BSUID ahora para que la asociación exista cuando los usernames comiencen a adoptarse masivamente.

La Timeline Completa del Cambio

Meta planificó el despliegue en fases bien definidas. Entender cada etapa es esencial para priorizar las acciones de tu equipo técnico:

El punto crítico en el que muchas empresas fallan es pensar que el cambio solo importa en junio. En realidad, la ventana de oro es ahora: desde principios de abril hasta junio, puedes capturar los BSUID de toda tu base de clientes activos a través del Contact Book, sin esperar a que adopten usernames. Quienes lo hagan tendrán la transición más fluida posible.

Cómo Cambia el Webhook en la Práctica

Para quienes trabajan directamente con la API, el cambio en el payload del webhook es concreto. Así es como queda la estructura del mensaje inbound:

{
  "contacts": [
    {
      "profile": {
        "name": "João Silva"
      },
      "wa_id": "5511999991234",
      "user_id": "BR.13491208655302741918",
      "username": "joaosilva"
    }
  ],
  "messages": [
    {
      "from": "BR.13491208655302741918",
      "id": "wamid.xxx",
      "timestamp": "1748822400",
      "text": { "body": "Olá, preciso de ajuda" },
      "type": "text"
    }
  ]
}

Ten en cuenta que ahora hay tres campos en el objeto de contacto: wa_id (que puede estar ausente para usuarios con username), user_id (el BSUID, siempre presente a partir de marzo de 2026) y username (el handle, si el usuario lo ha adoptado). El campo from en los mensajes también pasa a aceptar el BSUID directamente.

Cualquier sistema que haga const customerId = message.from y asuma que el resultado siempre es un número de teléfono debe ser revisado. El campo from puede ser un BSUID.

Qué Hacer con los Mensajes Sin Número de Teléfono

Una de las preguntas más frecuentes es: ¿y cuando el cliente es identificado únicamente por el BSUID, sin teléfono? La respuesta depende de tu caso de uso.

Para una atención al cliente estándar, el BSUID es suficiente. Puedes responder a la conversación, registrar el historial, activar automatizaciones e incluso identificar al cliente si ya está vinculado al BSUID en tu CRM. La ausencia de teléfono no impide la atención.

Para casos donde el teléfono sea necesariocomo autenticación por OTP, envío de SMS de confirmación o integración con sistemas heredados que solo aceptan teléfono, Meta creó un flujo nativo de recopilación. WhatsApp ofrece un botón de llamada a la acción (CTA) en el que el usuario hace clic para autorizar el uso compartido de su número con la empresa. Esto se basa en el consentimiento: el usuario elige si lo comparte o no.

{
  "type": "interactive",
  "interactive": {
    "type": "cta_url",
    "body": {
      "text": "Para continuar, necesitamos su número de teléfono."
    },
    "action": {
      "name": "phone_number_share",
      "parameters": {}
    }
  }
}

Importante: los mensajes de autenticación (OTP) solo funcionan con número de teléfono. El BSUID no reemplaza al teléfono para este tipo de comunicación. Si tu bot de onboarding depende de la verificación por SMS, este flujo debe ser revisado para solicitar el número antes de enviar el OTP.

Impacto en el CRM: De la Dimensión Única al Modelo Híbrido

El cambio más profundo no es técnico, sino del modelo de datos. Hoy en día, la mayoría de los CRM utilizan el teléfono como clave primaria o como único identificador de WhatsApp. Este modelo debe evolucionar hacia lo que los expertos llaman identidad bidimensional: teléfono Y BSUID como campos independientes, pudiendo ambos servir como clave de búsqueda.

La migración del esquema implica al menos cuatro pasos. Primero, añadir el campo bsuid en la tabla de contactos o clientes. Segundo, asegurar que el campo acepte valores nulos (para clientes que nunca han interactuado por WhatsApp después de marzo de 2026). Tercero, crear un índice de búsqueda en el campo BSUID; las consultas de búsqueda deberán ser rápidas. Cuarto, implementar la lógica de fusión (merge): cuando llegue un mensaje con BSUID y teléfono, cruzarlo con los registros existentes para evitar duplicados.

ALTER TABLE contacts ADD COLUMN whatsapp_bsuid VARCHAR(135) UNIQUE;
CREATE INDEX idx_contacts_bsuid ON contacts (whatsapp_bsuid);

El riesgo de no hacer esto es la proliferación de registros duplicados. El mismo cliente entra por teléfono en febrero y por nombre de usuario en agosto, y terminas con dos perfiles en el CRM, dos historiales separados, y el agente que atiende en agosto no sabe que el cliente ya fue atendido seis meses antes.

La Lógica de Deduplicación Correcta

La lógica de identificación de clientes debe ser reimplementada con una estrategia de fallback. La jerarquía recomendada es:

1. Buscar por BSUID → campo user_id del webhook
2. Si no se encuentra, buscar por teléfono → campo wa_id
3. Si no se encuentra en ninguno, crear un nuevo registro con el BSUID
4. Si se encuentra por teléfono pero no tiene BSUID, actualizar el registro con el BSUID

Este flujo garantiza que los clientes existentes sean identificados correctamente, independientemente de si han adoptado un username o no, y que el BSUID se vaya completando progresivamente en tu base de datos.

async function resolveContact(webhook: WhatsAppWebhook): Promise<Contact> {
  const bsuid = webhook.contacts[0]?.user_id;
  const phone = webhook.contacts[0]?.wa_id;
 
  // Intento 1: BSUID
  if (bsuid) {
    const byBsuid = await db.contacts.findByBsuid(bsuid);
    if (byBsuid) return byBsuid;
  }
 
  // Intento 2: teléfono
  if (phone) {
    const byPhone = await db.contacts.findByPhone(phone);
    if (byPhone) {
      if (bsuid && !byPhone.bsuid) {
        await db.contacts.update(byPhone.id, { bsuid });
      }
      return byPhone;
    }
  }
 
  // Nuevo contacto
  return db.contacts.create({ phone, bsuid });
}

BSUID y Privacidad: Qué Significa para el Usuario

Desde el punto de vista del usuario, el BSUID es una protección de privacidad elegante. Al adoptar un username, el usuario puede interactuar con decenas de empresas sin revelar nunca su número de teléfonoun dato que hoy en día se utiliza para spam de SMS, rastreo de identidad entre plataformas y, en casos extremos, acoso.

La propiedad "business-scoped" del identificador va más allá: incluso si tú (empresa A) y la empresa B (competidor) compartieran todos los BSUID de sus clientes, sería imposible cruzar qué usuarios son los mismos. Juan Silva tiene el ID BR.aaaa1111 contigo y BR.bbbb2222 con el competidor; son cadenas de texto completamente diferentes.

Este es un posicionamiento claro de Meta en respuesta a las críticas sobre privacidad que la plataforma ha recibido en los últimos años. WhatsApp, con sus 3000 millones de usuarios globales, es una plataforma demasiado privilegiada como para permitir que el teléfono sirva como vector universal de rastreo.

Para las empresas, esto significa que la era de tratar al teléfono como el identificador único universal de WhatsApp ha terminado. El dato de identidad pasa a ser el BSUID: válido únicamente dentro de tu portafolio, no exportable, y renovado si el usuario cambia de número.

Portabilidad de WABA: Un Detalle Crítico

Existe un detalle que la mayoría de las guías sobre BSUID no mencionan y que puede generar dolores de cabeza severos para empresas que cambian de BSP (Business Solution Provider): al migrar tu WABA a otro proveedor, Meta genera nuevos BSUID para todos los clientes.

Esto significa que si estás almacenando BSUID en el CRM y decides cambiar de plataforma de atención, todos los BSUID guardados dejarán de ser válidos tras la migración. La asociación deberá rehacerse y el Contact Book comenzará desde cero.

La implicación práctica es simple: elige bien tu plataforma de atención antes de comenzar a almacenar BSUID en producción. Una migración de WABA después de que la base de clientes esté identificada por BSUID es significativamente más compleja que una migración hoy en día.

Qué Cambia en los Anuncios Click-to-WhatsApp

Los anuncios Click-to-WhatsApp (CTWA) son uno de los flujos más afectados por el cambio. Hoy en día, cuando alguien hace clic en un anuncio e inicia una conversación, el sistema recibe el teléfono y puede identificar inmediatamente al lead, cruzarlo con el CRM y activar automatizaciones de calificación.

Con los usernames, un usuario que tiene @handle y hace clic en el anuncio iniciará la conversación sin revelar su teléfono. El campo from en el webhook será un BSUID desconocido para el CRM. El sistema deberá crear un nuevo perfil basado únicamente en el BSUID y, si necesita el teléfono para la calificación o el seguimiento por otros canales, solicitarlo explícitamente.

Para campañas de rendimiento que miden el CAC (Costo de Adquisición de Clientes) y realizan atribución, esto complica el seguimiento. Si hoy en día utilizas el teléfono para cruzar el lead de WhatsApp con el registro en el CRM de ventas, este flujo deberá adaptarse para aceptar el BSUID como identificador primario de atribución.

Chatbots y Automatizaciones: Qué Debe Cambiar

Para las operaciones que dependen de chatbotsya sea para calificación de leads, autoservicio o triaje, el cambio principal es: no asumas que el teléfono estará disponible desde el inicio de la conversación.

Los bots que hacen const cpf_check = await buscarCadastro(message.from) y asumen que message.from es un teléfono deben ser revisados. A partir de junio, message.from puede ser un BSUID. La búsqueda debe contemplar ambos escenarios.

Además, si el bot solicita documento de identidad o correo electrónico para la identificación y utiliza el teléfono como confirmación secundaria, el flujo debe adaptarse. El teléfono deja de ser información que el sistema tiene automáticamente y pasa a ser información que debe solicitarse cuando sea necesario.

La buena noticia es que para la mayoría de los flujos de atenciónapertura de casos, consulta de pedidos, preguntas frecuentes automatizadas, el teléfono nunca fue realmente necesario. Lo que se necesitaba era el identificador único del cliente, que ahora puede ser el BSUID.

Cómo Solicitar el Número de Teléfono Cuando Sea Necesario

Cuando el negocio realmente necesita el teléfonopara OTP, integración con sistemas heredados o confirmación de entrega, el enfoque correcto es solicitarlo explícitamente utilizando el flujo nativo de WhatsApp.

El mensaje debe ser claro y contextualizado, explicando por qué el número es necesario. Meta exige que la solicitud esté justificada y que el usuario tenga control sobre si lo comparte o no. Los enfoques coercitivos o que bloquean la atención si no se proporciona el número van en contra de las políticas de la plataforma y pueden resultar en la suspensión de la WABA.

La mejor práctica es hacer que el teléfono sea opcional siempre que sea posible y crear una ruta alternativa de atención para quienes no deseen compartirlo. En muchos casos, el BSUID es suficiente para ofrecer una experiencia completa de atención, y forzar la recopilación del teléfono va en contra de la tendencia de privacidad que Meta está estableciendo.

Qué Cambia para Quienes Utilizan Plataformas de Atención

Si utilizas una plataforma de atención (helpdesk, chatbot como servicio, etc.) en lugar de integrarte directamente con la API, la responsabilidad técnica de adaptar los webhooks y el esquema de datos es de la plataforma, no de tu empresa.

Pero eso no significa que puedas simplemente esperar. Lo que debes verificar es: ¿la plataforma que utilizo se está adaptando al BSUID en los plazos correctos? La lista de verificación mínima:

• ¿Se está capturando el campo BSUID en los webhooks desde el 31 de marzo?
• ¿El CRM de la plataforma ya tiene un campo para el BSUID en el perfil del contacto?
• ¿La deduplicación ya incluye búsquedas por BSUID?
• ¿Existe una comunicación clara sobre cuándo estará disponible?

Las plataformas que no respondan estas preguntas de manera satisfactoria para mayo de 2026 representan un riesgo operativo real para el segundo semestre.

Usernames para Empresas: Cómo Reclamar el Tuyo

No solo los usuarios pueden tener nombres de usuario; las empresas también. Meta está liberando para los negocios la posibilidad de reclamar un handle basado en el nombre de visualización registrado en la WABA, en la cuenta verificada de Meta Business, o en los handles de Facebook e Instagram.

Tener un username empresarial tiene beneficios directos: los clientes pueden encontrar tu negocio por el handle, sin necesidad de guardar el número. El enlace wa.me/c/tudelegacion funciona en anuncios, biografías de Instagram, firmas de correo electrónico y códigos QR. Es una mejora significativa en el descubrimiento y la conversión.

La ventana para reclamarlo comienza en junio de 2026. Las empresas con cuenta WABA verificada tienen prioridad. Se recomienda encarecidamente asegurarse de que el nombre de visualización de la WABA sea correcto y esté actualizado antes de esa fecha; el username se derivará de él.

Análisis de Impacto por Tipo de Operación

El impacto del BSUID varía significativamente dependiendo del perfil de la operación:

Atención al cliente (CS) Impacto medio. El historial de clientes existentes está protegido por el Contact Book. El mayor riesgo está en la apertura de casos por parte de nuevos clientes sin teléfono. La adaptación en la deduplicación lo resuelve.

Ventas y SDR vía WhatsApp Impacto alto. La calificación de leads depende frecuentemente de cruzar el contacto de WhatsApp con el CRM de ventas. Con el BSUID como identificador, el recorrido del lead debe ser rediseñado.

Marketing y campañas Impacto alto. Las listas de difusión existentes (outbound hacia números conocidos) no cambian. Pero los nuevos leads captados a través de CTWA pueden llegar sin teléfono, afectando la segmentación y las automatizaciones de nutrición.

Soporte técnico y CX Impacto bajo a medio. Siempre que la plataforma de atención se adapte correctamente, el agente no notará diferencias en el servicio. El historial unificado es el mayor beneficio: un cliente que cambia de número pero mantiene su username sigue siendo reconocible a través del BSUID.

El Nuevo Paradigma de Identidad en WhatsApp

Es útil dar un paso atrás y entender el movimiento más amplio que representa el BSUID. Meta está construyendo una infraestructura de identidad que funciona sin depender del número de teléfono. Esto no es solo privacidad; es la preparación para un futuro donde WhatsApp se utilice en dispositivos sin tarjeta SIM, en cuentas corporativas desvinculadas de números personales y, potencialmente, en otros contextos donde el teléfono no sea el vector natural.

El BSUID es la primera pieza de este rompecabezas. Garantiza que, incluso sin el teléfono, la identidad del usuario sea estable, verificable y única dentro de la relación con una empresa. El siguiente paso lógico es imaginar autenticaciones mediante llaves de paso (passkeys), inicio de sesión sin número y cuentas de WhatsApp vinculadas a identidades digitales más ricas.

Para el mercado latinoamericano y español de atención al clienteque es, a través de WhatsApp, uno de los más sofisticados del mundo, esto representa una oportunidad. Las empresas que construyan una arquitectura de datos y una estrategia de atención preparada para el BSUID hoy en día estarán años por delante de las que esperen a que llegue el cambio para reaccionar.

El Plan de Acción en 5 Etapas

Independientemente de tu stack tecnológico, este es el recorrido recomendado para prepararte:

Etapa 1 Diagnóstico (ahora)
Mapea todos los sistemas que reciben o envían datos por WhatsApp. Haz una lista de todos los puntos donde se asume que el teléfono es obligatorio: campos de bases de datos, validaciones de formularios, lógicas de deduplicación, consultas de CRM, API internas.

Etapa 2 Actualización del esquema (abril/mayo)
Añade el campo BSUID en todos los sistemas relevantes. Haz que el teléfono sea opcional donde sea posible. Implementa la lógica de búsqueda bidimensional (BSUID + teléfono).

Etapa 3 Recopilación y enriquecimiento (a partir de abril)
Comienza a capturar los BSUID de los webhooks desde ahora. El Contact Book de Meta ya estará mapeando los pares teléfono ↔ BSUID; utiliza este período para enriquecer tu base de clientes existente.

Etapa 4 Prueba (mayo/junio)
Utiliza la ventana de pruebas de Meta en mayo para enviar mensajes utilizando el BSUID. Valida el proceso de extremo a extremo: llega una nueva conversación solo con BSUID → la deduplicación funciona → historial correcto → se entrega la respuesta.

Etapa 5 Monitoreo post-lanzamiento (junio en adelante)
Monitorea las métricas de duplicidad de contactos, conversaciones perdidas y tasas de resolución. Los problemas en estas métricas después de junio pueden indicar que la adaptación al BSUID no fue completa.

Qué está Haciendo Tolky

Tolky sigue de cerca los cambios en la API de Meta y está adaptando toda la infraestructura de identificación de contactos para soportar el BSUID nativo. Esto incluye el esquema de datos, la deduplicación inteligente y la integración con el Contact Book de Meta.

Para nuestros clientes, la transición será transparente: el historial de atención continuará unificado, los BSUID se capturarán automáticamente y la plataforma sabrá buscar el contacto correcto independientemente de si el mensaje llega con teléfono o con BSUID. No será necesaria ninguna acción técnica por parte de tu equipo.

Si utilizas una plataforma diferente, ahora es el momento adecuado para preguntar a tu proveedor cuál es su plan para el BSUID. La respuesta que recibas dirá mucho sobre la madurez técnica de la solución que estás utilizando.

El cambio del BSUID no es el fin del número de teléfono en WhatsApp. La gran mayoría de tus clientes seguirá interactuando con su número visible durante bastante tiempo. Pero es el comienzo de una nueva era en la que la identidad del usuario le pertenece al usuariono al canaly las plataformas de atención deberán ser más sofisticadas para mantener el ritmo.

Quienes se preparen ahora pasarán por esta transición sin turbulencias. Quienes esperen descubrirán el problema por sus síntomas: duplicados en el CRM, historial perdido y automatizaciones que "simplemente dejaron de funcionar" para una parte creciente de los contactos.

La elección, como siempre, es decidir cuándo quieres que te sorprenda: ahora, cuando aún hay tiempo de actuar con calma, o después, cuando el problema ya esté en producción.