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

# Samples

> The runnable samples and copy-into-your-code clients in the repository: what each one shows, where it lives and how to start it.

The repository ([veriqa.app/source](https://veriqa.app/source)) carries a gallery of samples under
`samples/`. Everything there is **MIT-licensed** and written to be lifted into your own project.

<Note>
  **Veriqa lives on the issuer side.** An application that only signs users in stays a plain
  OpenID Connect relying party — no Veriqa package, no SDK. Veriqa packages appear only where the
  application *is* the issuer (embedded) or calls the confirmation API server-to-server.
</Note>

Samples come in two forms:

* **Runnable** — projects with their own `README.md`, ports and configuration. A .NET sample starts
  with `dotnet run --project <path>`; the samples outside .NET that run next to Veriqa start with
  `docker compose up` in their folder.
* **Code to copy** — one file per stack with the complete client wiring. There is no project file
  around it: the surrounding application is yours.

## Scenario samples

Each one shows one mechanism and nothing else.

| Path | What it shows | Form |
| - | - | - |
| `dotnet/inproc/login` | Sign-in with Veriqa embedded in the application: the issuer runs inside the process | runnable · `https://localhost:7300` |
| `dotnet/inproc/login-client` | The relying party of that issuer: a stock ASP.NET Core OIDC client with nothing Veriqa-specific in it | runnable · `https://localhost:7020` |
| `dotnet/inproc/confirmation` | Server-to-server confirmation of a backend action — no sign-in, no browser redirect | runnable · `https://localhost:7310` |
| `dotnet/inproc/step-up` | Step-up before a destructive action: only the owner of the account may confirm it | runnable · `https://localhost:7330` |
| `dotnet/inproc/agent-approval` | Human-in-the-loop approval of an AI agent's tool call | runnable · `https://localhost:7340` |
| `dotnet/aspire/login` | The same sign-in under .NET Aspire, with the transaction store as an orchestrated resource (needs Docker) | runnable · `https://localhost:7320` |
| `dotnet/custom-channel` | A third-party channel plugged in through the public SPI — see [Custom channel adapter](/docs/guides/custom-channel-adapter) | runnable · `https://localhost:7320` |
| `python/custom-channel-telegram` | Telegram through an external adapter in Python, plugged in by configuration — see [An HTTP channel adapter in any language](/docs/guides/custom-channel-adapter#an-http-channel-adapter-in-any-language) | runnable · `docker compose` |
| `node/custom-channel-whatsapp-twilio` | WhatsApp through Twilio, an external adapter in Node — see [An HTTP channel adapter in any language](/docs/guides/custom-channel-adapter#an-http-channel-adapter-in-any-language) | runnable · `docker compose` |
| `node/custom-channel-whatsapp-baileys` | WhatsApp through Baileys, an external adapter in Node — a working adapter for debugging WhatsApp scenarios, small teams and your own use; **an unofficial WhatsApp Web client, the number may be banned**; see [An HTTP channel adapter in any language](/docs/guides/custom-channel-adapter#an-http-channel-adapter-in-any-language) | runnable · `docker compose` |
| `dotnet/remote/login` | A client of an external issuer (self-hosted or Veriqa Cloud) | code to copy |
| `java/Application.java` | The same client on Spring Security OAuth2 Client | code to copy |
| `node/index.ts` | The same client on `openid-client` + Express | code to copy |
| `python/main.py` | The same client on Authlib + FastAPI | code to copy |
| `docker-compose/` | Self-hosted auth server behind Nginx with PostgreSQL, Redis and RabbitMQ — demonstration only | deployment |

The Aspire sample and the custom-channel host share port 7320 — run them one at a time.

## Agent harness sample

`claude-code/` is a Claude Code plugin rather than a .NET project: chosen agent actions — a
`git push`, the start of a long command cycle, a costly run with a token estimate — wait until a
person approves them in the messenger, with a chain of two approvers for the costly run. See
[Approvals in Claude Code](/docs/research/claude-code-approvals) and the sample's README.

## Showcase samples

The two samples under `samples/dotnet/showcase/` imitate a whole product, so the flows can be seen
end to end the way a user meets them. Each is one process in three roles: the embedded issuer, the
OIDC client of the browser, and the backend that creates confirmations.

<CardGroup cols={2}>
  <Card title="Nova Stream — streaming on a TV" icon="tv">
    `dotnet/showcase/streaming-tv` · `https://localhost:7350`. Sign-in by QR from the sofa, a
    welcome card from the channel's claims, recognition of a returning viewer, step-up when buying
    a title. Remote-control navigation, written for TV browsers (Tizen 5.5, webOS 5) and runnable
    behind an HTTP tunnel.
  </Card>

  <Card title="Helio — customer support" icon="headset">
    `dotnet/showcase/support-desk` · `https://localhost:7360`. A public support page, sign-in, the
    customer's card, and step-up before a ticket is closed or deleted.
  </Card>
</CardGroup>

What they show on top of the scenario samples:

* **The person's card** from the claims the channel gave: name, picture, `@username` and a masked
  user id (Telegram), a masked phone (WhatsApp), an address (Email). Identifiers are masked on the
  server; the full value never reaches the browser.
* **Step-up addressed to the signed-in person.** The confirmation names the identity of the current
  session (`expected_identities`), and the operation is applied only when `matched_type` agrees — a
  confirmation from another account changes nothing.
* **Receipts that differ by purpose.** A sign-in's question is replaced by "Sign-in to … confirmed ✅"
  (`ReplacePrompt`); a confirmation keeps its question and gets the receipt as a message of its own
  (`NewMessage`, stated in the backend client's entry). See
  `OutcomeNotice` in [Configuration](/docs/reference/configuration).
* **Veriqa's own pages, branded.** The sign-in page and the confirmation window are the product's
  screens; only brand, colour, theme and — for the television — a stylesheet are set through
  `AuthPageDesign`.

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

## Running the .NET samples

* .NET SDK 10.0+ and a trusted local HTTPS certificate (`dotnet dev-certs https --trust`).
* **Enable at least one channel and give it credentials.** Every sample ships with all channels
  `"Enabled": false`; with none enabled the sign-in page answers `no_channels_available`. A bot
  token is the quickest route — see [Channel setup](/docs/guides/channels) and the sample's own README.
* Pairs such as `login` + `login-client` start issuer first: the client fails discovery otherwise.


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