> ## Documentation Index > Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt > Use this file to discover all available pages before exploring further. # Получение телефона и email > Как приложение получает номер телефона и адрес почты пользователя: что даёт канал, что Veriqa добирает внутри входа и почему значения приходят подтверждёнными. Номер телефона и адрес почты приходят приложению в claims `phone_number` и `email`. Часть каналов отдаёт их сами, а недостающие приложение получает в одном из двух режимов: * **При первом входе.** Veriqa добирает телефон или email внутри того же входа, до выдачи токенов. Нужен ли claim и можно ли его пропустить, задаёт его уровень в каталоге [`Veriqa:ScopesClaims`](/docs/ru/reference/configuration#veriqascopesclaims) — см. [Сбор дополнительных claims](/docs/ru/concepts/claim-enrichment). * **Позже, при необходимости.** Пользователь входит без контактов. Когда телефон или email понадобились, приложение запускает новый authorize-запрос со `scope=phone` или `scope=email`, и пользователь подтверждает его в мессенджере. Второй режим показывает [пример-витрина Helio](/docs/ru/samples/showcase/support-desk): вход не просит контактов, а телефон и email клиент подтверждает позже, каждый своим запросом. ## При первом входе ### Телефон Номер Veriqa запрашивает у пользователя в самом канале. Как это устроено в каждом канале и доказана ли принадлежность номера, описано на странице [Номер телефона](/docs/ru/guides/phone-number). ### Email Адрес Veriqa добирает письмом, которое подтверждает адрес, или письмом от пользователя. Доступные способы задаёт `ClaimCompletionEmailMethods` [записи клиента](/docs/ru/reference/configuration#clients). Пользователь видит не больше трёх способов, в порядке списка: * **Подтвердить по email** — пользователь вводит адрес и нажимает одну кнопку. Что придёт, решает список, а не пользователь: код для ввода на странице (`Code`), ссылка на страницу подтверждения (`MagicLink`) либо одно письмо с тем и другим (`claim-code-link-mail`), когда список называет оба. В последнем случае адрес подтверждает то, что пользователь сделает первым. `email_verified` — `true`; * **письмо от пользователя** (`Push`) — на устройстве, где подтвердили вход; `email_verified` — `true`; * **без подтверждения** (`Unverified`) — адрес только вводится; `email_verified` — `false`. Значение, введённое в остальные поля формы, сохраняется на каждом шаге с email — запрос письма, ввод кода, смену способа. «Продолжить» есть всегда: нажатая до подтверждения адреса, она сохраняет поля, а страница говорит «Подтвердите адрес, чтобы продолжить.» Нажатая с кодом или адресом, набранным в блоке email, она вместо этого делает то, для чего это поле: проверяет код, отправляет письмо либо сохраняет адрес без подтверждения — а остальные поля оставляет без изменений. Следующее письмо нельзя запросить раньше, чем через `Veriqa:Channels:Email:MailResendInterval` после предыдущего — см. [Повторная отправка письма](/docs/ru/guides/channels#повторная-отправка-письма). Что показывает блок email на разных шагах: * **После отправки письма** — поле кода и **«Отправить снова»**. «Отправить снова» само ничего не отправляет: оно возвращает поле адреса, заполненное адресом последнего письма, чтобы пользователь либо отправил то же письмо ещё раз, либо сначала исправил адрес. * **Код, исчерпавший попытки,** возвращает блок к тому же полю адреса, пока письма в лимитах остались; когда их нет, блок говорит «У кода не осталось попыток.» и больше ничего не предлагает. Отказ по лимиту писем на адрес говорит «На этот адрес отправлено слишком много писем. Попробуйте позже или введите другой адрес.» * **Если адрес подтверждён ссылкой из письма** — например, открытой на телефоне, — форма на устройстве, где начат вход, узнаёт об этом сама: она продолжает так, будто нажата «Я подтвердил адрес», и сохраняет введённое в остальные поля. Страница, перешедшая на опрос, оставляет для этого кнопку. * **Записанный адрес** остаётся в блоке, пока в форме открыты другие поля: «Адрес … подтверждён», либо «Адрес … сохранён» — для адреса, принятого без подтверждения. Страница ссылки из письма предлагает **«Отмена»** рядом с «Подтвердить адрес» и **«Закрыть»** после подтверждения адреса; обе кнопки только закрывают вкладку. ## Позже, при необходимости Первый вход берёт минимум: `sub` и то, что даёт канал. Перед действием, которому нужен контакт, приложение запускает новый authorize-запрос со `scope=phone` или `scope=email`. Пользователь подтверждает его в мессенджере, и claim попадает в `id_token`. Как это устроено в [Helio](/docs/ru/samples/showcase/support-desk), описано на странице примера; общая схема — в [Сборе дополнительных claims](/docs/ru/concepts/claim-enrichment). ## Почему данные подтверждены Разница с анкетой в том, **кто источник значения**. Адрес, введённый в форму, — утверждение пользователя; адрес, полученный claim-ом с канала Email, — следствие того, что человек подтвердил вход именно из этого ящика. Проверять его отдельным письмом уже не нужно. То же с тем, что добирает Veriqa: номер, переданный в канале, и адрес, подтверждённый кодом, приходят с `phone_number_verified` / `email_verified`, а поле формы — это то, что пользователь ввёл. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.