Every applicant reaches their verification through an invite link. The link is single-use, scanner-safe, and bound to one verification.

## What the link contains

The applicant URL has two parts:

```
https://verify.<region>.<apex>/v/<short-code>?o=<otl-token>
```

- **`<short-code>`** identifies the verification. Safe to log. Shown in QR codes.
- **`?o=<otl-token>`** authorizes the applicant. Never logged. Only the first human click consumes it.

Both halves are minted at verification creation and reused by the email invite, the QR code, and any manual share.

## Why links are single-use

Resumable links let anyone with the URL re-open the verification. Two problems: email scanners that follow links land on the applicant's verification, and a forwarded link can be opened by the wrong person. A single-use link cuts both off.

## Scanner-safe consumption

The flow:

1. The applicant clicks the link. Their browser hits `/v/<code>?o=<otl>` on the verify app.
2. The resolver 302-redirects to a "Start verification" interstitial at `/start/<code>?o=<otl>`. This redirect does **not** consume the token.
3. The interstitial validates the token via a read-only validation call and renders one button.
4. Clicking the button POSTs a JSON consume request. Only this POST mints the journey cookie and marks the token consumed.
5. Subsequent clicks on the original URL find a valid journey cookie and continue into the verification, with no re-consume.

GET-only crawlers never burn the link. A real applicant click is required, and replays are rejected. The validation gate evaluates in order (consumed, expired, mismatch, OK), so a spent link always reads as a replay regardless of its other attributes.

## What the applicant sees

For the full walk-through, see [What the applicant sees](/guides/verification/applicant-experience). The invite-link hop:

- The interstitial shows your organization name and a "Start verification" button.
- Tapping the button transitions into the journey shell.
- If the applicant closes the tab and reopens the link, the journey cookie still authorizes them, with no re-consume.

## When a link is rejected

The verify app routes every failure to the branded `/expired` page. There are no distinct messages, no oracle for scanners. The failure classes:

- **Consumed.** The token has already been spent. The platform logs `kyc.applicant_link.replay_rejected`.
- **Expired.** The token is valid for 24 hours from issue.
- **Mismatch.** The `?o=` value does not match the verification.
- **Missing token.** The applicant landed on `/v/<code>` without `?o=`.
- **Unknown code.** The short code does not resolve in this region. See [Data residency](/guides/faq/data-residency).

## Issue a new link

From the applicant detail page click **Regenerate link**. The endpoint mints a fresh token on the same verification record, invalidates the previous one, and audits the action. The previous link's next click reads as a replay.

The applicant can also self-service from `/expired`: they request a fresh link without operator involvement. The verification has to still be in a non-terminal state.

For terminology, see the [Glossary](/glossary).