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

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

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

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

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

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

• Пользователь активно решает поделиться им
• Уже существует предыдущий диалог между пользователем и компанией
• Компания сохранена в контактах WhatsApp пользователя

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

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

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

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

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

• Он автоматически генерируется WhatsApp
• Он появляется в payload вебхуков (как 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.
• Реализуйте процесс запроса авторизации по телефонному номеру.
• Убедитесь, что сообщения с кодом подтверждения отправляются с использованием телефонных номеров.
• Завершите проверку тестовой среды.
• Подготовьте план поэтапного внедрения (серая версия).

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, уникальный идентификатор, представляющий пользователя для вашего бизнеса.
  Он всегда будет присутствовать и должен использоваться для идентификации пользователей, когда номер телефона недоступен.
  
  
  

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

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

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