TL;DR: Июньское обновление passkeys в WhatsApp 2026 года вводит строгую проверку WebAuthn, которую headless-серверы не могут подделать. Если ваша интеграция на Baileys или Puppeteer выдает ошибку 428, переходите на Whapi.Cloud и используйте решение Manual Paste — оно позволяет внедрить одноразовый payload и мгновенно восстановить подключение.
Июньское обновление 2026 года: почему боты внезапно перестали работать
В конце июня 2026 года WhatsApp внедрил серверное обновление, которое остановило работу продакшен-ботов по всему миру. Интеграции на базе Baileys, whatsmeow и whatsapp-web.js начали внезапно возвращать ошибки 428 при привязке устройств.
WhatsApp активировал процесс привязки «Shortcake», который требует passkey для подключения нового устройства. Это затрагивает именно тот этап сопряжения, на котором работают автоматизированные аккаунты — в результате библиотеки с открытым исходным кодом, зависящие от QR-кодов, моментально перестают функционировать. Мы наблюдали, как высоконагруженные аккаунты, использующие неофициальные интеграции Baileys для CRM-систем, внезапно останавливались из-за агрессивных ограничений Passkeys.
Как WebAuthn блокирует headless-серверы
Headless-серверы не могут выполнить navigator.credentials.get(), так как у них нет аппаратного аутентификатора и они не могут подтвердить идентификатор проверяющей стороны (relying-party) whatsapp.com.
Протокол WebAuthn от W3C использует аппаратную криптографию для предотвращения удаленного перехвата сессий. Представьте, что это банкомат. WhatsApp — это банк, Passkey — ваша физическая банковская карта, мобильное приложение WhatsApp — местное отделение, а WhatsApp Web — сам банкомат. Когда вы привязываете устройство, банкомат просит банк проверить вашу карту. Банк отправляет криптографический запрос (challenge), который может подписать только физическая карта.
// Without a hardware authenticator, headless Puppeteer fails here
// The promise rejects with: DOMException: The operation either timed out or was not allowed.
const credential = await navigator.credentials.get({
publicKey: {
challenge: serverChallenge,
rpId: "whatsapp.com",
userVerification: "required"
}
});
У headless-контейнера Chromium, запускаемого в дата-центре, нет физической карты. Подделать подписанное подтверждение вне реального браузера невозможно без доступа к закрытому ключу созданного passkey. API WebAuthn требует проверки домена на соответствие идентификатору whatsapp.com — поэтому headless-клиент отклоняется, и возвращается постоянная ошибка «Что-то пошло не так».
Процесс привязки «Shortcake» и недостатки UX
Недоработки в пользовательском интерфейсе (UX) WhatsApp приводят к бесконечным циклам ошибок, когда passkeys не совпадают в синхронизированных аккаунтах Google или когда не удается выполнить привязку по Bluetooth.
Как только пользователь создает passkey, WhatsApp начинает требовать его при всех будущих привязках устройств. Если удалить passkey с устройства, но он останется активным на серверах WhatsApp — пользователь потеряет доступ. Подобные сложности создают проблемы для обычных пользователей и становятся непреодолимым препятствием для автоматизированных систем.
Скрытая цена «бесплатных» библиотек с открытым исходным кодом
Бесплатные библиотеки скрывают огромные затраты на поддержку: когда WhatsApp внедряет недокументированные криптографические обновления, командам приходится использовать ручные обходные пути, которые не масштабируются.
Когда вышло обновление passkeys, первым решением сообщества стало ручное извлечение сессий. Нужно было авторизоваться в официальном клиенте WhatsApp Web, извлечь данные аутентифицированной сессии и внедрить их в библиотеку. На практике команды быстро понимают, что такое ручное извлечение не подходит для автоматизированных CRM-платформ, управляющих сотнями номеров.
Этот инцидент показывает реальную стоимость собственной инфраструктуры. Открытый исходный код ломается неожиданно, а последствия ложатся на плечи разработчиков и операторов. Whapi.Cloud берет на себя адаптацию к изменениям протокола — это сохраняет стабильность клиентского API и снижает риск внезапных сбоев из-за скрытых обновлений.
Как разблокировать интеграцию: решение с помощью Manual Paste
Функция Manual Paste от Whapi внедряет безопасный одноразовый payload, чтобы обойти ограничения WebAuthn и восстановить подключение за несколько минут.
Whapi.Cloud предлагает оптимизированное решение, которое избавляет от необходимости использовать сложные экстракторы сессий. Функция Manual Paste позволяет сгенерировать необходимое подтверждение WebAuthn в вашем локальном браузере и безопасно передать его в ваш инстанс Whapi.Cloud.
Payload — это одноразовая криптографическая подпись, которая истекает немедленно. Вы копируете скрипт с запросом из панели Whapi, вставляете его в консоль вкладки WhatsApp Web с выполненным входом и возвращаете подписанное подтверждение. Это позволяет обойти ограничения headless-режима, не раскрывая ваши закрытые ключи.
Подробные инструкции можно найти в руководстве Whapi.Cloud по новому этапу с passkey.
Что дальше: AutoPasskey
Будущая функция AutoPasskey от Whapi полностью скроет от разработчиков сложный процесс подтверждения W3C.
Хотя Manual Paste решает текущую проблему, в долгосрочной перспективе необходимо полностью отказаться от использования браузера. Whapi.Cloud активно разрабатывает AutoPasskey — решение, которое будет автоматически обрабатывать ограничения проверяющей стороны. Переход на управляемую облачную инфраструктуру гарантирует, что ваша интеграция переживет следующее недокументированное обновление протокола.
