> ## 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.

# Getting the phone number and email

> How an application gets the user's phone number and email address: what the channel gives, what Veriqa collects inside the sign-in, and why the values arrive verified.

The phone number and the email address reach the application in the `phone_number` and `email`
claims. Some channels give them on their own; when they are missing, the application gets them in
one of two modes:

* **At the first sign-in.** Veriqa collects the phone number or email inside the same sign-in,
  before it issues the tokens. Whether the claim is needed and whether the user may skip it is set
  by its level in the [`Veriqa:ScopesClaims`](/docs/reference/configuration#veriqascopesclaims) catalog —
  see [Collecting extra claims](/docs/concepts/claim-enrichment).
* **Later, when needed.** The user signs in without any contact details. When the phone number or
  email is needed, the application starts a new authorize request with `scope=phone` or
  `scope=email`, and the user confirms it in the messenger.

The [Helio showcase sample](/docs/samples/showcase/support-desk) shows the second mode: the sign-in asks
for no contact details, and the customer confirms the phone number and email later, each with a
request of its own.

## At the first sign-in

### Phone number

Veriqa asks the user for the number in the channel itself. How this works in each channel, and
whether ownership of the number is proven, is covered in [Phone number](/docs/guides/phone-number).

### Email

Veriqa collects the address by an email that confirms it or by an email the user sends. The
available methods are set by `ClaimCompletionEmailMethods` of the
[client entry](/docs/reference/configuration#clients).
The user sees at most three options, in the order of the list:

* **Confirm via email** — the user types the address and presses one button. What arrives is
  decided by the list, not by the user: a code to enter on the page (`Code`), a link to a
  confirmation page (`MagicLink`), or one email with both (`claim-code-link-mail`) when the list
  names both — whichever the user does first confirms the address. `email_verified` is `true`;
* **an email the user sends** (`Push`) — on the device that confirmed the sign-in; `email_verified` is
  `true`;
* **without confirmation** (`Unverified`) — the address is only typed; `email_verified` is `false`.

A value typed into the other fields of the form survives every step of the email flow — requesting
the email, entering the code, switching the method. "Continue" is always there: pressed before the
address is confirmed, it saves the fields and the page says "Confirm the address to continue."
Pressed with a code or an address typed into the email block, it does what that input is for instead
— checks the code, sends the email, or saves the address without confirmation — and leaves the other
fields as typed. Another email cannot be requested sooner than
`Veriqa:Channels:Email:MailResendInterval` after the previous one — see
[Sending an email again](/docs/guides/channels#sending-an-email-again).

What the email block shows as the user proceeds:

* **After the email is sent**, the code field and **Send again**. "Send again" sends nothing by
  itself: it brings back the address field, filled with the address of the last email, so the user
  either sends the same email once more or corrects the address first.
* **A code whose attempts are spent** turns the block back to that address field while emails are
  left within the limits; when none are left, the block says "The code has no attempts left." and
  asks for nothing more. When the per-address limit is reached, the block says "Too many emails have
  been sent to this address. Try again later or enter another address."
* **An address confirmed by the link in the email** — opened on a phone, say — reaches, on its own,
  the form on the device the sign-in started on: the form continues as if "I have confirmed the
  address" were pressed, keeping what the user typed into the other fields. A page that fell back to
  polling keeps the button for that.
* **A recorded address** stays in the block while other fields of the form are still open: "The
  address … is confirmed", or "The address … is saved" for an address taken without confirmation.

The page the link in the email opens offers **Cancel** beside "Confirm the address", and **Close**
once the address is confirmed; both only close the tab.

## Later, when needed

The first sign-in takes the minimum: `sub` plus whatever the channel gives. Before the action that
needs a contact, the application starts a new authorize request with `scope=phone` or
`scope=email`. The user confirms it in the messenger, and the claim arrives in the `id_token`. The
sample page describes how [Helio](/docs/samples/showcase/support-desk) does it; the general scheme is in
[Collecting extra claims](/docs/concepts/claim-enrichment).

## Why the data is verified

The difference from a form is **who the source of the value is**. An address typed into a form is the
user's word; an address that arrives as a claim from the Email channel follows from the
person having confirmed a sign-in from that very mailbox. There is nothing left to verify with a
separate email. The same holds for what Veriqa collects: a number shared in the channel and an
address confirmed by a code come with `phone_number_verified` / `email_verified`, while a form field
is what the user typed.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.