Миграция на BSUID в WhatsApp стартует 7 июля — чек-лист из пяти пунктов для команд, работающих только с входящими — UnifyPort
Meta меняет способ идентификации пользователей в API WhatsApp. С 7 июля 2026 года (Wave 1) в каждом вебхук-событии появится новое поле — Business-Scoped User ID (BSUID). А для тех пользователей, которые перейдут на имена пользователей WhatsApp, номер телефона может вообще перестать передаваться.
Если вы получаете сообщения из WhatsApp в рамках очереди поддержки, CRM-интеграции или конвейера AI-агентов — эта миграция затрагивает ваш код. Насколько глубоко — зависит от того, каким путём сообщения WhatsApp попадают в ваш бэкенд.
Эта статья — чек-лист. Пять областей для проверки, одна матрица решений и прямой ответ на вопрос, который на самом деле волнует большинство небольших команд: «Нужно ли мне что-то делать до 7 июля?»
Что такое BSUID
Каждый пользователь WhatsApp получает новый идентификатор — Business-Scoped User ID. Формат: двухбуквенный код страны, точка и до 128 алфавитно-цифровых символов, например BR.1A2B3C4D5E6F7G8H9I0J. Ключевое свойство: один и тот же человек получает разный BSUID для каждого бизнеса, с которым он взаимодействует. Ваш BSUID для пользователя Алисы — не тот же, что BSUID для Алисы у другой компании.
График развёртывания Meta:
| Волна | Дата | Охват |
|---|---|---|
| Wave 1 | 7 июля 2026 | Первые рынки |
| Wave 2 | 20 июля 2026 | Расширенное развёртывание |
| Глобально | Сентябрь 2026 | Все остальные рынки |
BSUID начали появляться в вебхук-данных ещё 31 марта 2026 года — как новое поле user_id. Но критическое изменение наступает с Wave 1: как только пользователь активирует имя пользователя WhatsApp, его номер телефона может больше не передаваться в полях wa_id и from.
Чек-лист: пять областей для проверки
1. Парсинг вебхук-данных
Что меняется: В каждом вебхуке сообщений появляется новое поле user_id. Для пользователей с именем пользователя поля wa_id и from, которые раньше содержали номер телефона, могут содержать BSUID или отсутствовать вовсе.
Что проверить: Ваш обработчик вебхуков предполагает, что from — это всегда номер телефона? Применяет регулярное выражение для цифр, использует его как ключ базы данных или передаёт в библиотеку валидации телефонных номеров? Любой из этих сценариев сломается, когда в from вместо 5511999887766 окажется BR.1A2B3C4D5E....
2. CRM и сопоставление контактов
Что меняется: Если ваша CRM хранит записи клиентов по номеру телефона, сообщение от пользователя с именем пользователя может прийти вообще без номера. Найти клиента не получится.
Что проверить: Может ли ваша база контактов хранить и сопоставлять BSUID наряду с номерами телефонов? Meta предоставляет Contact Book API, который сохраняет маппинг «номер телефона → BSUID» из предыдущих разговоров, но вызвать его нужно до того, как номер телефона исчезнет из новых вебхуков.
3. История переписки и группировка сообщений
Что меняется: Если вы группируете диалоги по номеру телефона (например, «покажи все сообщения от +5511999887766»), сообщения того же человека начнут приходить с BSUID-идентификатором. История переписки расколется надвое, если не связать старые записи по номеру с новым BSUID.
Что проверить: Используется ли номер телефона в качестве первичного ключа для ниток диалогов? Если да, запланируйте миграцию данных: свяжите существующие записи с их BSUID через маппинг Contact Book до наступления Wave 1.
4. Шаблонные и исходящие сообщения
Что меняется: При отправке шаблонных сообщений (исходящие) вам в конечном итоге нужно будет адресовать получателей по BSUID, а не по номеру телефона — особенно для пользователей с именами пользователей, чьи номера больше не передаются.
Что проверить: Если вы отправляете проактивные сообщения (подтверждения заказов, уведомления о доставке, напоминания о встречах), ваша логика отправки работает через номер телефона? Вам нужно будет сохранять BSUID из последнего входящего сообщения и использовать его для будущих исходящих вызовов.
5. Хранение данных и комплаенс
Что меняется: BSUID — это новый вид персональных данных. Они привязаны к конкретному бизнесу (их нельзя использовать для перекрёстного анализа пользователей между компаниями), но по большинству нормативных актов это всё равно PII.
Что проверить: Покрывает ли ваша политика хранения данных новый тип идентификатора? Если у вас есть процедуры удаления по GDPR/PDPA, которые перечисляют все хранимые идентификаторы пользователя, BSUID необходимо включить в этот перечень.
Какой у вас путь интеграции?
Не каждой команде нужно проходить все пять пунктов чек-листа. Всё зависит от того, каким образом сообщения WhatsApp попадают в ваш бэкенд.
| Путь интеграции | Пункты чек-листа | Объём работы |
|---|---|---|
| Cloud API (напрямую) | Все пять | Высокий — вы парсите сырые вебхуки Meta, и каждое изменение формата бьёт по вашему коду |
| BSP (Wati, 360dialog и т.д.) | Пункты 2, 3, 4, 5 | Средний — BSP может абстрагировать формат вебхуков, но CRM и логику отправки обновлять всё равно придётся |
| Неофициальный интерфейс входящих | Ни одного | Нулевой — читайте дальше |
Почему неофициальный входящий интерфейс не затронут
Если ваши сообщения из WhatsApp приходят через неофициальный интерфейс UnifyPort, миграция BSUID не затрагивает ваш пайплайн. Причина проста: UnifyPort не маршрутизирует сообщения через Cloud API от Meta. Неофициальный путь подключается к WhatsApp напрямую — так же, как это делает обычный телефон с WhatsApp, — поэтому сообщения, приходящие на ваш вебхук, изначально не были в формате Cloud API.
Ваш вебхук продолжает получать те же события message.received, что и раньше:
{
"event": "message.received",
"account_id": "acct_3qPmRz",
"provider": "whatsapp",
"from": "user_88c1ae",
"text": "Привет, заказ #2241 уже отправлен?",
"timestamp": 1751875200,
"message_id": "wa_msg_f4e29a"
}Поле from — это собственный нормализованный идентификатор пользователя UnifyPort, а не номер телефона и не BSUID. Оно никогда и не было номером телефона, поэтому при изменении схемы идентификации Meta мигрировать нечего. Сопоставление контактов в CRM, группировка диалогов и парсинг вебхуков — всё продолжает работать без изменений.
Верификация подписи HMAC-SHA256 на вашем вебхук-эндпоинте тоже не затронута — секрет подписи и формат подписи принадлежат UnifyPort, а не Meta.
Что делать на этой неделе
Если вы на Cloud API или BSP: начните с пункта 1 (парсинг вебхуков). Залогируйте выборку входящих вебхуков и проверьте, появилось ли уже поле user_id — оно разворачивается с 31 марта. Если поле есть — ваши данные уже меняются. Пройдите пункты 2–5 до 7 июля.
Если вы на неофициальном входящем интерфейсе: ничего не меняется. Миграция BSUID — это тема Cloud API, а ваши сообщения через Cloud API не проходят. Продолжайте строить.