Skip to main content
Используйте шаблон аутентификации для отправки одноразового пароля (OTP) для подтверждения личности, например при входе в систему, восстановлении аккаунта или подтверждении транзакции. Meta требует использовать для этих целей шаблоны аутентификации. Не отправляйте коды подтверждения личности через маркетинговые или сервисные шаблоны. Содержимое аутентификации использует строгий формат, а не произвольное рекламное сообщение.

​
Выберите способ доставки кода

Выбирайте самый простой способ, который ваше приложение может надежно поддерживать. Не выбирайте доставку в одно касание или без касания только потому, что редактор шаблонов предлагает такую возможность. Неподдерживаемые устройства или неудачные проверки соответствия могут использовать резервный вариант с копированием кода. Meta также описывает нативные подсказки клавиатуры для OTP на iOS 26 и новее, начиная с 15 июня 2026 года; это поведение клиента отличается от интеграции Android в одно касание и без касания. Протестируйте реальную комбинацию устройства клиента и приложения перед релизом.

​
Ознакомьтесь с содержимым шаблона

Формат аутентификации включает код подтверждения, действие по доставке кода и поддерживаемый текст безопасности или срока действия. Он не предназначен для медиафайлов, рекламного текста или общих уведомлений об аккаунте.
Сообщение аутентификации Meta с указанием кода, предупреждением безопасности, предупреждением об истечении срока действия и кнопкой автозаполнения.

Authentication content uses preset text and a code-delivery action. Meta labels each part in this example.

Источник: официальный пример Meta. Кнопка купона Копировать код относится к маркетинговому формату; это не шаблон аутентификации. Используйте настройки шаблонов аутентификации в YCloud и руководство по API шаблонов для просмотра поддерживаемых полей.

​
Разделяйте три вида срока действия

Отображение предупреждения об истечении срока действия не заставляет ваш бэкенд отклонять просроченный код. Настройте саму систему верификации. Выбирайте срок доставки, соответствующий полезному времени жизни кода. Запоздалое сообщение с просроченным кодом ухудшает процесс входа, даже если сообщение доставлено успешно.

​
Настройте код так, чтобы он оставался актуальным при доставке

В YCloud выберите Authentication, укажите способ доставки кода и настройте поддерживаемые параметры безопасности и срока действия. Текст сообщения строго ограничен; не вставляйте обычный маркетинговый шаблон в эту категорию. Для гипотетического кода, действительного в течение пяти минут: Текущий контракт шаблонов YCloud поддерживает значения аутентификации messageSendTtlSeconds от 30 до 900 секунд со значением по умолчанию 10 минут для вновь создаваемых шаблонов аутентификации. Ранее созданные шаблоны могут иметь другие значения по умолчанию; проверяйте сохраненные настройки, а не предполагайте, что все существующие шаблоны одинаковы. Отображаемый параметр срока действия поддерживает диапазон 1–90 минут, однако эта настройка отображения не расширяет допустимый диапазон срока доставки. TTL в пять минут не гарантирует, что после получения останется пять минут: часть времени уже прошла с момента выпуска кода. Ваше приложение должно показывать фактическое оставшееся время жизни.

​
Поддерживайте актуальность параметров интеграции с Android

Для форматов One-tap и Zero-tap требуются совпадающие идентификаторы приложения и работающее рукопожатие. Текущий контракт шаблонов YCloud использует supported_apps; устаревшие поля верхнего уровня package_name и signature_hash больше не рекомендуются к использованию. Текущая документация Meta по аутентификации указывает 15 октября 2026 года как крайний срок перехода с устаревшего рукопожатия PendingIntent и рекомендует OTP Android SDK. Если ваше приложение использует этот старый процесс, рассматривайте миграцию как задачу на уровне приложения, а не просто редактирование текста шаблона. Перед релизом ознакомьтесь с актуальной документацией по One-tap и Zero-tap.

​
Тестируйте сценарии сбоев

Протестируйте сценарии с истекшим кодом, повторным запросом кода, неверным кодом, устройством в офлайне, неподдерживаемым клиентом и несоответствием подписи Android-приложения. Определите, аннулирует ли выпуск нового кода предыдущий, и настройте интерфейс в соответствии с этим решением. Никогда не делайте вывод об успешной аутентификации на основе delivered или read. Только ваш бэкенд верификации может определить, действителен ли отправленный код для конкретного пользователя и действия.

​
Спроектируйте процесс верификации

  1. Позвольте клиенту запросить код и подтвердить номер назначения.
  2. Предупредите, что код будет доставлен через WhatsApp.
  3. Генерируйте и проверяйте код в вашей системе верификации.
  4. Отправляйте одобренный шаблон с обязательными параметрами.
  5. Отслеживайте доставку сообщений отдельно от успешного прохождения верификации.
  6. Предоставляйте возможность контролируемой повторной отправки или альтернативный маршрут при необходимости.
Применяйте ограничения по частоте запросов (rate limits) и контроль повторных попыток для запросов кода. Никогда не считайте отчет о доставке или прочтении в WhatsApp подтверждением того, что клиент успешно прошел аутентификацию. Не записывайте действующие коды верификации в общие журналы (логи) приложения.

​
Тарифы и доступность

Для сообщений аутентификации действуют отдельные тарифы, а в соответствующих условиях могут применяться международные тарифы на аутентификацию. См. раздел Цены WhatsApp. Запрос кода клиентом не является согласием на получение будущих несвязанных маркетинговых сообщений. Согласие и цель сообщения должны соответствовать запрошенной верификации.

​
Руководства по внедрению

Для изучения базовой логики Meta ознакомьтесь с разделом Шаблоны аутентификации.

​
Часто задаваемые вопросы

Сравните три временные метки: когда приложение сгенерировало код, сколько времени сообщение могло ожидать доставки и когда клиент отправил его. Текст срока действия в шаблоне не продлевает период действия кода на вашем сервере. Используйте TTL доставки, соответствующий полезному сроку жизни кода, аннулируйте замененные коды согласно вашей архитектуре безопасности и предоставьте возможность контролируемого запроса нового кода.
Нет. Эти форматы лишь изменяют способ, с помощью которого совместимое приложение получает или подставляет код. Ваш бэкенд по-прежнему должен проверять запрос, код, срок его действия и лимиты попыток. Доставленное/прочитанное сообщение или успешное автозаполнение не являются доказательством успешной верификации.
Проверьте совместимость клиента, одобренный формат аутентификации, а также зарегистрированные значения пакета (package) и подписи вашего приложения. На неподдерживаемых клиентах ожидаемо срабатывает резервный сценарий с копированием кода. Протестируйте тот же шаблон на поддерживаемых комбинациях приложений и клиентов, прежде чем делать вывод о неисправности шаблона.