Skip to main content
Номер телефона Veriqa берёт только из канала: его передаёт мессенджер, пользователь его не вводит. Поля телефона на странице входа нет, а номер, набранный в чате сообщением, не принимается. Ваше приложение получает его стандартным claim phone_number в формате E.164, рядом с phone_number_verified.

Когда Veriqa запрашивает номер

Veriqa спрашивает, только если номер нужен вашему приложению, а канал его ещё не дал. Нужность — это уровень требования claim phone_number: Требование действует, только если вход запрашивает scope phone. При Required окно входа предлагает только каналы, способные дать номер; если таких не осталось, /connect/authorize отвечает 400 no_channel_for_required_phone (разбор проблем). Запрос приходит, когда пользователь подтвердил вход — в чате или кнопкой «Да» на странице подтверждения в браузере. Бот отправляет его в тот чат, из которого пользователь входил: короткий текст, кнопку, которая делится номером, и вторую кнопку, смысл которой зависит от уровня. Тексты показываются на языке пользователя. Окно по умолчанию — 60 секунд. Меняется ключом Veriqa:ClaimCompletion:PhoneOptionalWindow, а для одного приложения — членом ClaimCompletionPhoneOptionalWindow его записи клиента (см. ключи в каталоге объявлений). Окно не заходит за срок транзакции: шаг пропускается не позже чем за 5 секунд до её истечения. Если присланный номер завершает вход, в чате появляется обычная квитанция подтверждённого входа; Отменить вход показывает квитанцию отклонённого.

Что получает ваше приложение

  • phone_number — в E.164: + и цифры. Номер, который не приводится к E.164, считается отсутствующим: он не выдаётся, а шаг ждёт так, будто пользователь не ответил.
  • phone_number_verified — JSON boolean: true, только если канал доказал, что номер принадлежит отправившему его пользователю, иначе false.
  • Оба claim выходят только под выданным scope phone.
Контакт, не прошедший проверку принадлежности в канале, — чужая карточка контакта, пересланный контакт, отсутствующая или неверная подпись — не принимается, и бот спрашивает снова. Запрос, который не удалось доставить в чат и после повторов, ничего не меняет: шаг ждёт так же, как без ответа.

По каналам

«Кто» — чей код получает номер: адаптер канала Veriqa или ваша собственная интеграция с платформой. Для каналов, адаптера которых ещё нет в поставке, указано, что позволяет API платформы.

MAX

Бот отправляет кнопку «поделиться номером» и callback-кнопку со вторым действием. Номер берётся из vcf_info, только если совпала подпись hash контакта — она вычисляется на токене бота того тенанта, который получил контакт. Номер телефона запрашивается только в режиме вебхука. При UpdateMode: Polling адаптер MAX телефон не объявляет и ничего не спрашивает: подпись читается из сырого тела вебхука, которого у polling нет, поэтому каждый контакт был бы отклонён. Required номер в этом режиме исключает MAX из окна входа.

Telegram

Бот отправляет reply-клавиатуру: сверху кнопка «поделиться номером», под ней вторая кнопка; после нажатия клавиатура скрывается. Veriqa принимает только собственный контакт пользователя: user_id контакта должен совпадать с отправителем, а пересланный контакт или карточка из записной книжки отклоняются. Вход на сайт через Telegram (Log In With Telegram) тоже умеет отдавать номер — это ваша собственная интеграция с Telegram, вне Veriqa.
Если апдейты бота раздаёте вы сами — один бот на ваш код и Veriqa, и ваш код решает, какой апдейт отдать Veriqa, через OwnsInboundEvent (см. телефон по запросу), — кнопки Пропустить и Отменить вход уходят вашему боту, а не Veriqa: в Telegram это обычные текстовые кнопки без маркера, по которому их можно узнать. Сам присланный контакт узнаётся. Optional номер тогда пропускается по окну, а Required ждёт до истечения транзакции.

WhatsApp

Сегодня номер приходит с каждым сообщением: WhatsApp узнаёт пользователя по номеру телефона, поэтому токен несёт phone_number с phone_number_verified: true, и ничего не спрашивается. Запрос нужен для пользователей, которых WhatsApp адресует без номера (business-scoped user IDs): интерактивное сообщение request_contact_info, а следом отдельное сообщение со второй кнопкой — своих кнопок у запроса нет. Карточка контакта, отправленная пользователем вручную (origin = other), отклоняется. Запрос отправляет поставляемый провайдер Meta Cloud API; собственный провайдер WhatsApp (IWhatsAppProvider) отправляет его, только если реализует SendContactRequestAsync, — иначе запрос не доставляется, и шаг ждёт так же, как без ответа.

LINE, KakaoTalk, WeChat и Zalo — ваша интеграция

Эти платформы отдают номер телефона только своему входу или мини-приложению, которые регистрируете вы и одобряет платформа, — не боту. Veriqa номер там не получает. Если вашему приложению он нужен от этих пользователей, получите его своим кодом через вход платформы и храните у себя.

Discord и Threema

Ни одна из платформ не отдаёт боту номер телефона пользователя.

Ограничения

  • Окно Optional номера держится в памяти того экземпляра, который отправил запрос. Если экземпляр остановился раньше, чем окно истекло, шаг не пропускается, и транзакция ждёт до истечения.
  • Запись, связывающая чат с ожидающим запросом, по умолчанию in-process. При нескольких репликах перенесите её в Redis вместе с остальными канальными хранилищами (канальные хранилища) — иначе номер, пришедший на другую реплику, запроса не найдёт.
  • Когда в одном чате номера ждут два входа, номер достаётся тому, чей запрос пришёл последним; второй ждёт своего окна или истечения.
  • Кнопки запроса остаются в чате, если шаг закончился без нажатия — истекло окно Optional номера, истёк вход. Veriqa их не убирает: в Telegram клавиатура остаётся под полем ввода, пока пользователь не нажмёт одну из её кнопок. Номер, отправленный из неё после этого, ожидающего запроса не находит и не принимается, бот на него не отвечает; нажатие второй кнопки тогда — обычное сообщение боту.