Всё, что нужно знать о WhatsApp Usernames и BSUID (начиная с июня 2026 года)

Почему WhatsApp вводит имена пользователей?

Что меняется?

Сообщения для аутентификации (верификационный код/OTP) должны отправляться по номеру телефона

Также есть важное ограничение: сообщения для аутентификации по-прежнему требуют номера телефона.
Вы не можете отправлять OTP или коды подтверждения, используя только BSUID. Если этот процесс важен для вашего бизнеса, вам нужен четкий способ запросить и сохранить номер телефона пользователя.

В некоторых случаях WhatsApp может по-прежнему передавать номер телефона бизнесу, например, когда:

• Пользователь активно выбирает его передачу
• Между пользователем и бизнесом уже существует диалог
• Бизнес сохранен в контактах WhatsApp пользователя

Таким образом, бизнесам теперь нужно поддерживать обе ситуации одновременно:

• Клиенты, идентифицированные только через BSUID
• Клиенты, идентифицированные по номеру телефона и BSUID

Вот почему это не просто обновление продукта. Это обновление системы.

Что такое BSUID (Business Scoped User ID)

Как работает BSUID

• Он автоматически генерируется WhatsApp
• Он появляется в данных вебхуков (как user_id)
• Он работает даже при отсутствии номера телефона
• Он привязан к конкретному бизнес-портфолио

Таким образом, с точки зрения системы это становится вашим идентификатор нового пользователя во входящих беседах.

Формат BSUID (Как Это Выглядит)

BSUID имеет фиксированную структуру:

• Начинается с ISO 3166 alpha-2 Двухбуквенного кода страны пользователя
• За которым следует точка (.)
• Затем уникальная буквенно-цифровая строка (до 128 символов)

Example:
US.13491208655302741918

При использовании в API значение должно использоваться точно как есть.
Любое изменение или усечение приведет к ошибке запроса.

Ключевые Правила, Которые Нужно Знать

• BSUID уникален для каждой пары бизнес-портфель и пользователь (бизнес-портфели ранее назывались Business Managers)
• Он генерируется заново, если пользователь меняет номер телефона (что вызывает вебхук системного статусного сообщения)
• Он ограничен бизнес-портфелем (не может использоваться для разных портфелей)
• Он появляется в вебхуках даже если пользователь не включил имена пользователей

Ограничения BSUID

BSUID мощный, но не полная замена номеров телефонов.

• Вы не можете отправлять аутентификационные сообщения (OTP, коды подтверждения) использование BSUID
• Для этих потоков по-прежнему требуется номер телефона
• Поэтому, если ваш сценарий использования зависит от OTP, вы должны запросить номер у пользователя

Что НЕ изменится

Механизмы отправки и получения сообщений

• Использование шаблонов сообщений остается без изменений.
• Поддержка различных типов сообщений (текст, изображения, видео, документы и т.д.) остается без изменений.
• Структура API для отправки сообщений в основном остается прежней, за исключением того, что параметр идентификатора должен быть совместим с BSUID.
• Бизнесы, у которых уже есть информация о номерах телефонов из существующих диалогов, не потеряют ее и смогут продолжать использовать их для общения с контактами.

Правила биллинга диалогов

• 24-часовое окно диалога остается без изменений.
• Метод биллинга диалогов остается прежним.
• Независимо от того, использует ли клиент номер телефона или имя пользователя, логика биллинга остается одинаковой.

Что еще?

• Номера телефонов по-прежнему будут частью работы WhatsApp.
• Если пользователь не перешел на имена пользователей, бизнесы будут получать как его номер телефона, так и идентификатор в рамках бизнеса.

Это означает, что бизнесам следует сосредоточить основные усилия на идентификации клиентов и ассоциации данных; основные возможности обмена сообщениями и бизнес-логика продолжат работать как прежде

Далее рассмотрим трудности, с которыми столкнутся бизнесы при адаптации к этой новой системе идентификации.

Проблемы, с которыми сталкиваются бизнесы

Проблема 1: Невозможность напрямую получить номера телефонов новых пользователей

Когда новый пользователь обращается, используя имя пользователя, вы получите только BSUID.

По умолчанию вы не получите их номер телефона.

Вы все еще можете отвечать и продолжать беседу, используя BSUID. Но если вашему бизнесу нужен номер телефона (например, для OTP или верификации), теперь вам придется явно запросить его в чате и ждать согласия пользователя.

Проблема 2: Сопоставление BSUID с существующими данными клиентов

Большинство CRM сегодня построены вокруг номеров телефонов.

• профили клиентов
• история чатов
• заказы
• сегментация

Все привязано к номеру телефона как к первичному ключу.

Теперь, с появлением BSUID, вам нужно решить:

• Добавлять ли BSUID как новое поле?
• Или создать отдельный слой сопоставления между номером телефона и BSUID?

Это не просто техническое решение, оно влияет на согласованность данных, логику запросов и сложность системы.

Проблема 3: Поддержание непрерывности диалога при переключении клиентов между разными идентификаторами

Со стороны пользователя ничего не меняется. Это все тот же диалог.

Но со стороны вашей системы могут возникнуть проблемы.

Пример:

• Первое взаимодействие → Идентифицировано через BSUID
• Позже → Пользователь указывает номер телефона

Если ваша система не связывает оба параметра корректно, один пользователь может рассматриваться как два разных клиента.

Последствия:

• Дублирующиеся записи
• Разорванная история переписки
• Плохой пользовательский опыт

Проблема 4: Обработка процессов верификации и OTP

BSUID нельзя использовать для аутентификационных сообщений.

Поэтому если ваш процесс включает:

• OTP
• Подтверждение входа
• Привязку аккаунта

Вам сначала необходимо запросить номер телефона пользователя.

Это означает, что текущие процессы могут потребовать переработки для:

• Явного запроса согласия
• Сбора номера
• Правильного хранения и сопоставления

Далее рассмотрим, что именно перестанет работать, если эти проблемы не решить.

Что сломается (если проигнорировать)

Вот что перестает работать:

• Вы можете пропускать диалоги
  Новые пользователи, приходящие по именам пользователей, могут некорректно отображаться в вашей системе.
  

• Нарушаются потоки сообщений
  Сервисные сообщения и потоки CTWA (Click-to-WhatsApp Ads) могут не запускаться должным образом.
  

• История чатов теряет связность
  Один и тот же пользователь может отображаться как несколько личностей.
  

• Данные в CRM становятся ненадежными
  Профили клиентов могут некорректно сохранять или сопоставлять данные.
  

• Увеличивается количество дубликатов пользователей
  Один пользователь = несколько записей по номеру телефона и BSUID.
  

• Автоматизация перестает работать
  Рабочие процессы, привязанные к номерам телефонов, не будут запускаться.
  

• Нарушаются сквозные рабочие процессы
  От захвата лидов до последующих действий — все начинает разваливаться.
  

• У продаж теряется видимость
  Лиды невозможно корректно идентифицировать или отслеживать.
  

Вот почему последствия серьезнее, чем кажется.
Это не просто проблема данных, это влияет на весь путь клиента.

Теперь давайте рассмотрим, как решить эту проблему и правильно настроить идентификацию клиентов.

Решения для идентификации клиентов

Сценарий 1: Новые клиенты, инициирующие контакт впервые через имя пользователя (только BSUID)

Когда новый клиент начинает разговор, используя имя пользователя, ваша система может получить только BSUID.

В этом случае BSUID становится отправной точкой для профиля этого клиента.

Вот как это обработать:

• Ваша модель данных должна поддерживать более одного идентификатора для одного клиента.
• Ваша CRM должна уметь создавать профиль клиента, используя BSUID.
• Ваша система должна поддерживать поиск и идентификацию с помощью BSUID.
• Если бизнесу нужен номер телефона (например, когда требуется адрес доставки или нужно отправить проверочный код), запросите его в нужный момент внутри разговора.
• Если пользователь его предоставит, сохраните этот номер и свяжите его с тем же профилем на основе BSUID.

Сценарий 2: Клиенты, чей номер телефона у вас уже есть

Если у вашего бизнеса уже есть номер телефона клиента, вы можете продолжать его использовать.

Эта часть не меняется.

Даже если пользователь активирует имена пользователей, вы всё равно можете отправлять сообщения, используя известный номер телефона. Но если тот же пользователь позже начнёт разговор, используя имя пользователя, ваша система должна уметь связать новый BSUID с существующей записью на основе номера телефона.

Вот как это обработать:

• Ваша модель данных по-прежнему должна поддерживать несколько идентификаторов для одного клиента.
• Когда появляется BSUID, свяжите его с существующей записью клиента.
• Ваша система должна поддерживать поиск по номеру телефона или BSUID.
• Приоритезируйте номер телефона для исходящих сообщений, особенно для процессов верификации или аутентификации

График и план действий

WhatsApp внедряет это поэтапно, что дает вам время на подготовку, но только если начать заранее.

График

• 31 марта 2026 → BSUID начнет появляться в Webhook.
• Май 2026 → Доступно тестирование BSUID (можно начинать отправку с использованием BSUID).
• Июнь 2026 → Пользователи в тестовых странах могут начать использовать юзернеймы. Начинается внедрение юзернеймов.
• Остаток 2026 года → Пользователи по всему миру могут начать использовать юзернеймы.

Что должны сделать бизнесы

1. Подготовительный этап (текущий)

• Изучите и поймите механизм BSUID и технические детали.
• Определите, где используются номера телефонов в рабочих процессах.
• Определите, как вы будете обрабатывать номер телефона и BSUID.
• Оценить масштаб и объем работ, необходимых для модификации существующих систем.
• Разработать планы по корректировке базы данных и обеспечению совместимости API.
• Начать технические исследования и проектирование решения.
• Согласовать действия внутренних команд (продукт, разработка, маркетинг) и спланировать стратегию работы с бизнес-именем пользователя.

2. Фаза реализации (перед запуском функции)

• Обновить CRM и базу данных для поддержки BSUID.
• Завершить преобразование интеграционного слоя API для обеспечения совместимости.
• Реализовать процесс авторизации по номеру телефона.
• Убедиться, что сообщения с проверочным кодом отправляются на номера телефонов.
• Завершить проверку тестовой среды.
• Подготовить план постепенного внедрения (gray release).

3. Тестирование

• Провести сквозное тестирование с реальными сценариями.
• Проверить:
  • Создание пользователей на основе BSUID
  • Процессы сбора номеров телефонов
  • Сопоставление идентификаторов
  • Потоки сообщений и автоматизации

4. Фаза запуска (после выхода функции)

• Внедрять поэтапно (не переключать все сразу).
• Мониторить работоспособность системы, включая точность создания профилей, успешность OTP и производительность процессов.
• Учитывать обратную связь пользователей и устранять аномалии.
• Оптимизировать логику идентификации клиентов.
• Постоянно улучшать точность ассоциации данных.
• Контролировать показатели авторизации по номеру телефона и оптимизировать время и содержание запросов.
• Зарегистрировать и настроить бизнес-имя пользователя.

Контрольный список перед запуском

Перед запуском убедитесь, что:

• BSUID интегрирован во все ваши системы.
• Вы по-прежнему можете отправлять и получать сообщения без номеров телефонов.
• Все рабочие процессы протестированы для обоих идентификаторов.
• Чат-боты и цепочки сообщений могут запрашивать номера телефонов при необходимости.
• Существующие рабочие процессы проверены и обновлены, чтобы избежать сбоев.

Приоритизация

• Высокий приоритет → Настройка структуры CRM и базы данных, модификации совместимости API, корректировка логики отправки проверочных кодов (влияет на основную функциональность).
• Средний приоритет → Адаптация систем поддержки клиентов, обновление маркетинговых систем (влияет на эффективность бизнеса).
• Низкий приоритет → Оптимизация отчетности по данным, очистка исторических данных (может быть доработана постепенно).

Это не то, что можно исправить в последний момент.
Чем раньше вы адаптируетесь, тем более плавным будет переход.

Где найти дополнительные ресурсы

Если вы внедряете это, не полагайтесь на предположения, используйте официальную документацию.

Вот ключевые ресурсы для начала:

• Руководство по BSUID
  https://docs.ycloud.com/reference/bsuid
  → Описывает, как работает BSUID, его формат и использование в API
  
  

• Обновления вебхуков (поля BSUID)
  https://docs.ycloud.com/reference/webhook-updates-bsuid
  → Помогает понять, как BSUID появляется в данных вебхуков и что меняется в интеграции
  
  

• Документация для разработчиков Meta (BSUID)
  https://developers.facebook.com/documentation/business-messaging/whatsapp/business-scoped-user-ids
  → Официальный справочник по введению и использованию BSUID в API WhatsApp
  
  

Это должны быть ваши основные справочные материалы при обновлении системы.

Подведем итоги!

Глоссарий

Вот ключевые термины, которые вы увидите в вебхуках и API, объясненные простым языком:

• contacts (новый массив)
  Список пользователей, участвующих в сообщении. Можно считать это «разделом с информацией о клиенте» в вебхуке.
  

• profile
  Основные сведения о пользователе внутри contacts.
  

• username
  Новый атрибут. Имя пользователя в WhatsApp (если оно установлено).
  Если пользователь не установил имя, это поле не будет отображаться.
  
  

• wa_id
  Новый атрибут. Номер телефона пользователя.
  Если номер телефона доступен, он будет отображен здесь.
  Если пользователь использует имя и номер не предоставлен, это поле может отсутствовать.
  
  
  

• user_id (BSUID)
  Новый атрибут. Наиболее важное поле в будущем.
  Это BSUID, уникальный ID, который представляет пользователя для вашего бизнеса.
  Он всегда будет присутствовать и должен использоваться для идентификации пользователей, когда номер телефона недоступен.
  
  
  

• parent_user_id
  Вышестоящий BSUID, который может работать с несколькими бизнес-портфелями (если включено).
  Большинству компаний это не понадобится, если только они не управляют несколькими портфелями.
  
  

Простой способ понять это:

• wa_id → Номер телефона (может быть доступен или нет)
• user_id → BSUID (всегда доступен, новый стандарт)
• username → То, что пользователь показывает публично