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

# Helio — customer support

> A showcase sample that imitates the support section of a website: a public page, sign-in, the customer's card and step-up before a ticket is closed or deleted.

Helio is a runnable emulator of a whole product rather than of one mechanism: the support section
of a fictional company's website. It strings together what an ordinary web product does — a page
anyone can read, sign-in, the person's data, and a confirmation before an action that matters — so
the flows can be seen end to end the way a customer encounters them.

`samples/dotnet/showcase/support-desk` · `https://localhost:7360`

<Note>
  The support page belongs to the fictional company. The sign-in page and the confirmation window
  are Veriqa's own screens, shown as they are: `AuthPageDesign` sets only the brand name, the logo,
  the primary color and shows the QR code only on a desktop.
</Note>

## What the customer sees

<Steps>
  <Step title="A public page">
    The support section is readable by anyone; nobody is redirected on arrival.
  </Step>

  <Step title="Sign-in">
    The visitor is sent to the Veriqa sign-in page and comes back signed in: with a QR code on a desktop, with
    the channel button on a phone. The sign-in asks for no contact.
  </Step>

  <Step title="The customer's card">
    The card is built from the claims the channel provides: display name, first and last name, picture,
    `@username` and a masked user id (Telegram). A phone or an address appears only once the customer
    has confirmed it. Next to it are the customer's tickets.
  </Step>

  <Step title="A contact when a feature needs it">
    "Call me back" and "Answer by e-mail" open once the customer confirms a phone number or an email
    address — each by one more authorize request. The request adds the scope and names the claim as
    essential in the `claims` parameter, and the application accepts the value only with its
    `*_verified` mark. See [Progressive claim enrichment](/docs/concepts/claim-enrichment).
  </Step>

  <Step title="Step-up">
    Closing or deleting a ticket is confirmed in the channel, **by that person**. The dialog on the
    page only guards against a misclick; the question in the channel is the one that decides.
  </Step>
</Steps>

The two flows leave different receipts in the chat. A sign-in's question is replaced by
"Sign-in to Helio Support confirmed ✅" (`ReplacePrompt`); a ticket action keeps its question and
gets the receipt as a message of its own (`NewMessage`, set in the backend client's entry), so
what was confirmed stays readable. See `OutcomeNotice` in [Configuration](/docs/reference/configuration).

## How it is built

One process plays three roles:

| Role | What it is |
| - | - |
| Embedded Veriqa issuer | `AddVeriqaAuthServer` → `UseVeriqaAuthServer` → `MapVeriqaAuthServer` |
| Browser-side OIDC client | the standard `AddOpenIdConnect` handler, pointed at this very process |
| Backend that creates confirmations | `VeriqaConfirmationClient`, calling the [server-to-server confirmation API](/docs/reference/confirmation-api) over HTTP |

**Step-up addressed to the signed-in person.** Closing and deleting a ticket are two declared action
types, `resolve-ticket` and `delete-ticket`, each with its own wording. Every confirmation names one
expected identity — the identity from the channel the current session came through
(`expected_identities`) — and the operation is applied only when `matched_type` agrees: a
confirmation from another account leaves the ticket untouched, as do a decline and an expiry.
The server remembers which ticket a transaction acts on, so no browser can delete one ticket
by confirming another.

**Identifiers stay on the server.** The full channel user id addresses the step-up and is never sent
to the browser: the user id and the phone number are masked before they are put into a response.

**No database.** The tickets are synthesized from the `sub` claim, so the same person sees the same
list on every visit. Only the tickets the customer has closed or deleted are kept in memory; a
restart forgets them.

<Note>
  This step-up goes through the server-to-server confirmation API. The other route — a repeat
  authorize and an `auth_time` check in the browser — is described in
  [Second factor, step-up and action approvals](/docs/scenarios/step-up).
</Note>

## Running it

Prerequisites:

* .NET SDK 10.0+;
* a trusted development certificate — the application calls **itself** over HTTPS:
  `dotnet dev-certs https --trust`;
* credentials for at least one channel. A Telegram bot token from
  [@BotFather](https://t.me/BotFather) is the shortest path.

Channels ship **disabled with empty credentials**: a channel switched on without its credentials
stops the application from starting. Switch on the ones you have and start the sample:

```bash theme={null}
dotnet user-secrets --project samples/dotnet/showcase/support-desk set "Veriqa:Channels:Telegram:BotToken" "<token>"
dotnet user-secrets --project samples/dotnet/showcase/support-desk set "Veriqa:Channels:Telegram:Enabled" "true"
dotnet run --project samples/dotnet/showcase/support-desk
```

Open `https://localhost:7360`. The sample wires the Telegram, WhatsApp and Email adapters; WhatsApp
and Email are switched on the same way, through their sections `Veriqa:Channels:WhatsApp:*` and
`Veriqa:Channels:Email:*` with `Enabled` set to `true`. The sign-in page offers exactly the
channels that are on — an empty sign-in page means none is enabled. Credentials for each channel are
described in [Channel setup](/docs/guides/channels).

<Tip>
  A Telegram bot delivers its updates to one webhook address, so with one bot token only one of the
  two showcase samples can take sign-ins at a time.
</Tip>

The sample also runs behind an HTTP tunnel, with Telegram switched to `Webhook` mode. The variables
to set, the API of the page and the details of the step-up are in the sample's `README.md` in the
repository ([veriqa.app/source](https://veriqa.app/source), path
`samples/dotnet/showcase/support-desk`) — it remains the detailed setup guide.

## Videos

<CardGroup cols={2}>
  <Card title="Sign-in on a desktop" icon="desktop" href="/docs/videos/desktop-sign-in">
    Sign-in by QR and the customer card built from the channel claims.
  </Card>

  <Card title="Sign-in on a phone" icon="mobile" href="/docs/videos/mobile-sign-in">
    No QR code — the channel button opens the messenger on the same device.
  </Card>

  <Card title="Step-up on a desktop" icon="desktop" href="/docs/videos/desktop-step-up">
    Deleting a ticket takes a confirmation in the messenger.
  </Card>

  <Card title="Step-up on a phone" icon="mobile" href="/docs/videos/mobile-step-up">
    Closing a ticket is confirmed in Telegram on the same device.
  </Card>
</CardGroup>

## See also

* [Showcase samples](/docs/samples#showcase-samples)
* [Second factor, step-up and action approvals](/docs/scenarios/step-up)
* [Server-to-server confirmation API](/docs/reference/confirmation-api)
* [Sign-in and channel linking in one action](/docs/scenarios/channel-linking)
* [Channel setup](/docs/guides/channels)


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