Configuration reference

Veriqa reads the host’s standard IConfiguration, so every setting can come from appsettings.json, environment variables, user-secrets or any other provider. Everything Veriqa owns lives under a single root key, Veriqa:

Section	Contents
`Veriqa`	The auth server: OIDC, transactions, sign-in page, limits, infrastructure
`Veriqa:Channels`	The channel adapters: Telegram, WhatsApp, other channels, Email

This reference answers “which setting controls it”. Two neighboring questions have pages of their own: what the specifications give you is in OIDC and OAuth 2.0 support, and what is missing is in Known limitations. In environment variables, : becomes __ — Veriqa:OpenIddict:Database:Provider is Veriqa__OpenIddict__Database__Provider. One shell limitation is worth knowing here. A POSIX shell allows only letters, digits and _ in a variable name, so export rejects the whole name as soon as any segment of the path carries a - or a .: export Veriqa__ChannelDisplay__Hints__my-channel=... fails as an invalid identifier. Where that segment comes from makes no difference. It may be a value you choose — the channel type in Veriqa:AuthPageDesign:QrCode:PixelsPerModuleByChannel:<channel type> and in Veriqa:ChannelDisplay:Hints:<channel type> (the channel type of an SPI adapter is allowed a hyphen), or the record code in the Veriqa:UiConfigurations:Records catalog. It may just as well be a fixed key name of the schema, which you do not choose at all — the message kind in Veriqa:MessageTemplates:confirmation-prompt. The variable name itself is perfectly legal, and the limitation is worked around with the usual tools: Docker (-e), Kubernetes variables (env:), launchSettings.json and a plain env NAME=VALUE command all accept such names, and .NET reads them as usual. A path whose segments hold only letters, digits and _ is set from an environment variable in the usual way. A configuration directory of its own. One variable does not name a setting but a place to read settings from: VERIQA_CONFIG_DIRECTORY points at a directory, and the host layers the appsettings.json and appsettings.<Environment>.json found there over the files shipped with the program and under the environment variables. Both files are optional; a directory that does not exist prevents startup, an empty one is not an error. This is how an installation made by the OS-service installer keeps its configuration — /etc/veriqa on Linux, %ProgramData%\Veriqa on Windows — where replacing the program cannot touch it.

Configuration is validated at startup. An unknown enum value, a relational provider without a connection string or an enabled channel missing its token stops the application immediately rather than failing later on a user’s first sign-in.

Veriqa:OpenIddict

OIDC server, its store and the registered clients.

Database

Key	Default	Meaning
`Provider`	— (no default)	Store for clients, authorizations and tokens: `InMemory`, `PostgreSQL` or `SqlServer`
`ConnectionString`	—	Required for any relational provider

Provider has no default: an unset value is not “InMemory by default”, it is a choice nobody made. Outside the Development environment such a host fails to start (the startup check names the fix); in Development it starts with a Warning. InMemory remains a valid value, but it is set explicitly and every restart invalidates issued tokens — fine for development and for a single-instance connector. In embedded mode these keys do not select the provider: there your host selects it by calling authServer.UseOpenIddictDatabase(...) or authServer.UseInMemoryOpenIddictStore(); in self-hosted mode the choice is set with these keys.

Server

Key	Default	Meaning
`Issuer`	host URL	Explicit issuer; needed when the public URL differs from the bound one
`AccessTokenLifetimeSeconds`	`3600`	Access token lifetime
`RefreshTokenLifetimeSeconds`	`1209600`	Refresh token lifetime (14 days)
`AuthorizationCodeLifetimeSeconds`	`300`	Authorization code lifetime
`EnableRefreshTokenRotation`	`true`	Issue a new refresh token on each use
`EnableRevocation`	`true`	Enable `/connect/revoke`
`TokenPruneIntervalSeconds`	`3600`	How often the background job deletes stale token and authorization records from the OpenIddict database. Must be greater than 0 and not exceed `4294967` (about 49.7 days, the longest wait a timer accepts), otherwise the host does not start
`TokenPruneThresholdSeconds`	`86400`	Minimum age of a token or authorization record, counted from its creation, before the job may delete it — and only once the record is no longer valid (expired or revoked). Valid records are never deleted, whatever the value. Must be greater than 0, otherwise the host does not start
`SigningCertificatePath` / `SigningCertificateBase64` / `SigningCertificatePassword`	—	Token signing certificate. Required outside `Development` (`Path` or `Base64`)
`EncryptionCertificatePath` / `EncryptionCertificateBase64` / `EncryptionCertificatePassword`	—	Token encryption certificate. Required outside `Development` (`Path` or `Base64`)

The behavior depends on the environment, and the difference matters:

Development — with no explicit certificates, development keys are generated. Convenient locally, but every restart produces new keys and multiple instances do not share them.
Any other environment — there are no development keys: the server refuses to start until both certificates (signing and encryption) are configured. There is no fallback to generation.

The shipped Docker image runs with ASPNETCORE_ENVIRONMENT=Production, so it follows the second rule. If you see generated development keys in a deployed installation, the process is running in Development — worth fixing before rollout.

Clients

Veriqa:OpenIddict:Clients is an array of the applications allowed to sign users in:

Key	Meaning
`ClientId`	Client identifier. Unique within the array: two entries sharing a `ClientId` prevent startup with a validation error — otherwise everything in the second entry would silently not apply
`DisplayName`	Name of this application in the texts of a sign-in the user receives in the channel and in the email — what fills their `{app}` slot. If unset or blank, the `ClientId` is used instead. It does not apply to the confirmations your server creates (`POST /api/transaction/confirmation`): there `{app}` is always the `ClientId`. The sign-in page does not show it: the name beside the logo there is stated by `BrandName`
`AllowedRedirectUris`	Exact-match list; no wildcards, absolute URIs only
`AllowedScopes`	Scopes the client may request. With a non-empty `Veriqa:ScopesClaims:Scopes` only the scopes of that catalog and `openid` — a scope outside it prevents startup: an application narrows the catalog, it does not widen it
`AllowRefreshTokens`	Whether `offline_access` is honored
`AllowClientCredentials`	Whether the client may use the Client Credentials grant — the way your server authenticates to create confirmation transactions (`POST /api/transaction/confirmation`) and read their result. Off by default. Confidential clients only (with a `ClientSecret`): enabling it on a public client prevents startup
`AllowIntrospection`	Whether the client may call the introspection endpoint `/connect/introspect` (RFC 7662). Off by default. Confidential clients only (with a `ClientSecret`): enabling it on a public client prevents startup. The response carries metadata only, and a client with this permission sees `sub` and `client_id` of tokens issued to other clients — grant it only to your own confidential clients. See OIDC and OAuth 2.0 support
`AllowConfirmationTokenGrant`	Whether the client may exchange a confirmed confirmation transaction it created for the `id_token` of the person who confirmed (grant `urn:veriqa:params:oauth:grant-type:confirmation`). Off by default. It is the integrator’s permission: no parameter of the application’s request widens what is disclosed, and the claims stay within `AllowedScopes`. Requires `AllowClientCredentials` and `openid` in `AllowedScopes` — without either, the host does not start. See Linking from your server
`AllowCollectedClaimsDeletion`	Whether the client may delete the collected claims of a subject with `DELETE /api/collected-claims` (the endpoint exists only when a collected claims store is registered). Off by default. It deletes the personal data of any subject of the client’s tenant, so grant it to one of your own server clients only; the endpoint has no rate limit of its own. Requires `AllowClientCredentials` — without it, the host does not start. See Storage
`TenantId`	Tenant this application belongs to. If unset or blank, the entry states no tenant and the transaction is created without one, which is how a self-hosted installation with a single tenant works. The value is read once per request, by each request that knows the client but has no transaction to take the tenant from: the sign-in and the server-to-server creation of a confirmation transaction store it on the transaction they create, and it travels on the transaction from there; the `form_post` response page is written from the HTTP request alone, without the transaction, and reads it again. The tenant is the level at which configuration keys resolve, not an access boundary: isolation is provided by `client_id`, which sits above the tenant
`RequirePhone` / `RequireEmail`	Whether this application requires `phone_number` / `email` — the same shorthand as in `Veriqa:ScopesClaims`. If unset, the global value applies. Stricter only: `false` here does not lift a requirement the global section states
`ClaimLevels`	Map of claim name → level (`IfAvailable`, `Optional`, `Required`) that RAISES the level the catalog row of that claim states, for this application only; a lower level changes nothing. Raising a claim Veriqa cannot complete (see `Level` in `Veriqa:ScopesClaims`) prevents startup
`ClaimCompletionFormEnabled`	Whether Veriqa shows its own claims completion form to the users of this application. If unset, `Veriqa:ClaimCompletion:FormEnabled` applies, and the form is on unless the global section states otherwise. `false` — a missing claim other than `phone_number` and `email` is issued only when the channel supplies it and never blocks the sign-in. Turn it off for a relying party with a profile completion form of its own — see Keycloak
`ClaimCompletionFormSurface`	Where Veriqa shows its claims completion form to the users of this application: `Auto`, `InitiatingPage`, `CrossDevicePage` or `CrossDevicePageOnly`. If unset, `Veriqa:ClaimCompletion:FormSurface` applies, `Auto` unless the global section states otherwise. `Auto` shows the form on the device that confirmed the sign-in when the sign-in was confirmed on the confirmation page of an Email Pull email (that page confirms it only with `LoginConfirmation.Mode` set to `None`; otherwise the sign-in window does), or when the channel account has no identifier to show (a Telegram account without a username), and on the sign-in page otherwise. `InitiatingPage` — always the sign-in page. `CrossDevicePage` — the device that confirmed the sign-in: the confirmation page of the email, or a page opened by a link button the channel sends into the chat; when the channel cannot show a link button, the issuer is not an absolute HTTPS URL or the button is not delivered, the form falls back to the sign-in page. `CrossDevicePageOnly` — the same without the fallback: a missing required claim then fails the sign-in with `required_claim_unobtainable`, and a missing optional one is skipped
`ClaimCompletionEmailMethods`	Ways of obtaining a missing `email` that this application allows: `Push`, `Code`, `MagicLink` and `Unverified`. If unset, the list of the tenant applies, or else `Veriqa:ClaimCompletion:EmailMethods` (`Push`, `Code`, `MagicLink` unless the global section states otherwise). Narrowing only: a method the list above does not name is dropped, and the order stays that of the list above. The first way available on the page is offered first, the others as alternatives: `Push` only on the device that confirmed the sign-in and with inbound email of the Email adapter, `Code` and `MagicLink` with its outbound email, `Unverified` always — the address is then not confirmed and `email_verified` is `false`. `Code` and `MagicLink` are not two ways the user picks between: together they stand for one way, “Confirm via email”, with one button, placed where the first of the two stands in the list. The list decides what its email carries: `Code` alone — a code to enter on the page (`claim-code-mail`); `MagicLink` alone — a link to a confirmation page (`claim-link-mail`); both — one email with a code and a link (`claim-code-link-mail`), and the address is confirmed by whichever the user does first. Two emails of this kind are not sent to one sign-in sooner than `Veriqa:Channels:Email:MailResendInterval` apart. With no method available a required `email` is not enforced; when this application requires the email and no method is available on the sign-in page, the host does not start. An empty list is refused — lower the requirement of the email instead
`ClaimCompletionEmailLimits`	Limits of the emails sent to obtain `email`: `CodeAttempts` (attempts per code, 5), `MailsPerTransaction` (3), `MailsPerSubject` (per channel account in 24 hours, 10), `MailsPerAddress` (per recipient address in an hour, 5), `MailsPerDomain` (per recipient domain in an hour; `0` — off, the default). If unset, the value of the tenant or of `Veriqa:ClaimCompletion:EmailLimits` applies. Stricter only: a larger value here does not lift a limit set above, and `0` does not switch off a domain limit set above
`CompatibilityQuirks`	Compatibility quirk keys from the closed registry — relaxations of the request form for this client. Unset by default; effective only while the gate below is open. See Client compatibility
`LogoUrl`	Logo of this application’s sign-in page; as in the global section, shown in every preset but `Minimal`. If unset, the logo comes from the level below; with neither a logo nor a brand name at any level the page shows the product’s own mark
`BrandName`	Brand name beside the logo of this application’s sign-in page; as in the global section, shown in every preset but `Minimal`. If unset or blank, the name comes from the level below. Resolved on its own, so this entry may state the name while the logo comes from elsewhere
`FooterHtml`	Footer block of this application’s sign-in page — your own markup at the bottom of the card. If unset or blank, the block comes from the level below: a blank value here does not switch off the block the global section states. Markup outside the admitted shape drops this client entry from the effective configuration whole, so every other setting of the entry then resolves from the level below — the shape and the outcomes are in Footer block of the sign-in page
`HopInstructionHtml`	Instruction this application’s sign-in page shows in place of the channel choice once the user has continued on the phone in hop mode — your own markup instead of the core’s text. If unset or blank, the instruction comes from the level below. The shape and the outcome of an inadmissible value are those of `FooterHtml`: the client entry is dropped whole — see Instruction after the scan
`AuthPage:Texts`	This application’s wording of the built-in texts of the pages Veriqa renders: a map “built-in text → replacement”, keyed by the English text of the element. A value is a replacement key that goes through the locale files, or an object of ready texts by language (`{ "en": "…", "ru": "…" }`) that bypasses them. An entry outranks the tenant’s entry for the same text and yields to the `ui_config` record’s; entries for other texts stated there stay in force. A text stated by its own setting (`BrandName`, `FooterHtml`, `HopInstructionHtml`, the `Title`/`Instruction` of a record) is not reworded. An entry for a text outside the open list, or a replacement whose slots differ, is not applied and is reported once — at startup and on a reload of the configuration; the client entry is not dropped for it. The forms, the rules and the open list are in Rewording a page element for one application
`PrimaryColor`	Accent color of this application’s sign-in page, `#RRGGBB`; applied only with `Preset: Branded`. If unset, the color comes from the level below
`LogoUrlByTheme`	This application’s logos for a single theme: a map `light`/`dark` → URL. A theme without a value of its own takes the `LogoUrl` of the same entry
`PrimaryColorByTheme`	This application’s accent colors for a single theme: a map `light`/`dark` → `#RRGGBB`. A theme without a value of its own takes the `PrimaryColor` of the same entry
`CustomCssPath` / `CssSriHash`	Custom stylesheet of this application’s sign-in page and its SRI hash. Resolved as a pair: the entry that states the path owns the hash as well; no path — both come from the level below
`CustomJsPath` / `JsSriHash`	Custom script of this application’s sign-in page and its SRI hash — the risky mode. Effective only while the gate `Veriqa:AuthPageDesign:CustomJsAllowApplicationOverride` is open; with the gate closed the script comes from the level below and a warning is written to the log at startup. Resolved as a pair, exactly like the CSS
`QrCode`	The sign-in page QR code for this client: the same keys as in the `Veriqa:AuthPageDesign:QrCode` section, each of them optional. If unset, the QR comes from the level below
`ChannelButton`	The channel buttons of this application’s sign-in page: `ShowChannelButton` — `Always`, `MobileOnly` or `Never`, as in the global section. If unset, the value comes from the level below. A pair with the effective `ShowQrCode` that leaves a device with neither the QR nor the button is not applied: the buttons are shown on every device and a warning goes into the log — see Allowed combinations
`ChannelLayout`	How several channels share this application’s sign-in page: `Tabs` or `Grid`. If unset, the layout comes from the level below. See Channel layout
`Cancel`	The cancel button of this application’s pages — “Cancel sign-in” in the sign-in window and “Cancel confirmation” on the page that opens a confirmation: `Enabled`, `true` or `false`. If unset, the value comes from the level below, and with no level stating it the button is on. See Cancel button

Next to the clients array sits the deployment gate:

Key	Default	Meaning
`CompatibilityQuirksAllowApplicationOverride`	`false`	While closed no quirk takes effect, whatever the clients list

Veriqa:TransactionEngine

The sign-in transaction lifecycle.

Key	Default	Meaning
`TransactionTtlSeconds`	`300`	How long the user has to confirm
`ConfirmationFinalizationTimeoutSeconds`	`30`	Window to finalize after confirmation
`CompletedRetentionSeconds`	`600`	How long a dead transaction — completed, failed or expired — stays readable before removal
`CleanupIntervalSeconds`	`15`	Expired-transaction sweep interval
`CleanupBatchSize`	`100`	Rows per sweep
`CleanupErrorRetryDelaySeconds`	`10`	Retry delay after a failed sweep
`MaxInMemoryEntries`	`10000`	Cap for the in-memory store
`RejectBots`	`true`	Reject transactions started by bots
`RejectBotsAllowApplicationOverride`	`false`	Let the application override that decision

Store

Key	Default	Meaning
`ConnectionString`	—	Set it to switch from in-memory to a durable store: a relational connection string, or a Redis one with `Provider` = `Redis`
`Provider`	`PostgreSQL`	`PostgreSQL` or `SqlServer` (EF Core), or `Redis`. Without `ConnectionString` the store stays in memory whatever the value
`KeyPrefix`	`veriqa:tx:`	Transaction key prefix, read only on `Redis`

See Storage for migrations and retention.

Veriqa:ScopesClaims

Which scopes exist, which claims they carry and which claims a sign-in requires.

Key	Default	Meaning
`Scopes`	—	Catalog of scopes, each with its `Name` and its `Claims` (keys below). If empty, the product’s own scopes are registered: `openid`, `profile`, `email`, `phone`, `offline_access`, `channel`, `avatar`
`RequirePhone`	`false`	Require `phone_number` — a shorthand for `Level: Required` on its claim. An application may require it on its own (`RequirePhone` of the client entry) but cannot lift it. It applies to a sign-in that asks for the `phone` scope: such a sign-in is offered only the channels able to provide the phone number, and with none of them available `/connect/authorize` answers `400` `no_channel_for_required_phone`
`RequireEmail`	`false`	Require `email` — the same shorthand for the email

A non-empty Scopes replaces the product’s own set of scopes as a whole: scopes_supported of discovery then lists exactly the scopes of the catalog (plus openid, which is always registered), and a request for any other scope is refused with invalid_scope. If your clients use offline_access, channel or avatar, list them in the catalog explicitly.

Keys of a claim in Claims:

Key	Default	Meaning
`Name`	—	Claim name as it appears in the token. One claim — one row. A claim of a standard scope (`name` of `profile`, `phone_number` of `phone`, `email` of `email`, …) may stand only under that scope
`Level`	`IfAvailable`	Requirement level: `IfAvailable` — issued only if the channel or the store already has it; `Optional` — the user is asked and may decline; `Required` — the sign-in does not complete without it. A level above `IfAvailable` needs a claim Veriqa can complete — `phone_number`, `email` or a row with `Completion`; on any other claim it prevents startup. An application may raise the level (`ClaimLevels` of the client entry), never lower it
`Source`	`Channel`	`Channel` — issued by the channel; `External` — added by your claims mapper after Veriqa; `Collected` — collected by Veriqa: never issued by a channel, taken only from the store or through completion, so it requires `Completion`
`Completion`	—	Description of the completion field: `Label` — the field label, a localization key, must not be blank; `MaxLength` — `256` by default, must be positive, applied to `Text` only; `Format` — `Text`, `Date` or `Choice`; `Options` — the values a `Choice` field offers, in the order listed, each a pair of `Value` (what the claim receives) and `Label` (the caption, a localization key like the field label). A `Choice` field is shown as a drop-down list with an empty first entry, and a value outside the list is refused. `Options` must not be empty for `Choice`; every `Value` is non-blank, has no white space at its edges, is at most 256 characters long and is stated once; every `Label` is non-blank; `Options` on a field of another format prevents startup. Admitted on `Channel` and `Collected` claims. Prevents startup on an `External` claim, on `phone_number` and `email` (they have their own paths) and on the claims the core issues itself: `sub`, `amr`, `auth_time`, `zoneinfo`, `updated_at`, `email_verified`, `phone_number_verified`, `channel_type`, `channel_user_id`, `is_bot`, `veriqa_channel`, `veriqa_email_mode`

Veriqa:AuthPageDesign

Look and feel of the sign-in page — full walkthrough in Configuration & customization.

Key	Default	Meaning
`Preset`	`Default`	Design preset; `Branded` enables `PrimaryColor`
`Theme`	`Auto`	`Auto`, `Light` or `Dark`
`LogoUrl`	—	Your logo, in every preset but `Minimal`. With neither `LogoUrl` nor `BrandName` stated the page shows the product’s own mark
`BrandName`	—	Brand name beside the logo, in every preset but `Minimal`. Unlike the logo it is cut by no theme — one name for both
`FooterHtml`	—	Footer block of the sign-in page: your own markup (legal links, a note, a contact) at the bottom of the card, in every preset. Markup outside the admitted shape prevents startup — the shape is in Footer block of the sign-in page
`HopInstructionHtml`	—	Instruction the sign-in page shows in place of the channel choice once the user has continued on the phone in hop mode: your own markup, in the shape of `FooterHtml`. If unset, the core’s own text is shown. Markup outside the admitted shape prevents startup — see Instruction after the scan
`PrimaryColor`	—	Accent color, `#RRGGBB`; applied only with `Preset: Branded`
`LogoUrlByTheme`	—	Logo for a single theme: a map `light`/`dark` → URL. A theme without a value of its own takes `LogoUrl`
`PrimaryColorByTheme`	—	Accent color for a single theme: a map `light`/`dark` → `#RRGGBB`. A theme without a value of its own takes `PrimaryColor`
`CustomCssPath` / `CustomJsPath`	—	External assets; a custom CSS path overrides the preset
`CssSriHash` / `JsSriHash`	—	Subresource Integrity hashes for those assets. A hash is resolved together with its path — both always come from the same level
`CustomJsAllowApplicationOverride`	`false`	Gate for the risky mode: lets a client entry (`Veriqa:OpenIddict:Clients`) state its own `CustomJsPath`/`JsSriHash`. Without it only this section supplies the script
`ChannelButton:ShowChannelButton`	`Always`	On which devices the button that leads into a channel (“Sign in with …”, “Confirm in …”, “Send confirmation email”) is shown: `Always` — on every device; `MobileOnly` — on a phone only; `Never` — nowhere, the QR is the only way in. A pair with `ShowQrCode` that leaves a device with neither the QR nor the button is not applied: the buttons are shown on every device and a warning goes into the log — see Channel button visibility
`ChannelLayout`	`Tabs`	How several channels share a page that shows a QR for each of them: `Tabs` — one at a time behind tabs; `Grid` — all at once, side by side. A page of one channel, a page laid out as channel buttons and a page with one QR code for all its channels — with or without the “Any channel” tab — are the same under either value — see Channel layout
`Cancel:Enabled`	`true`	Whether the cancel button is shown: “Cancel sign-in” in the sign-in window ends the sign-in and returns the user to the application with `error=access_denied`; “Cancel confirmation” on the page that opens a confirmation declines it and shows the “declined” receipt. On by default — see Cancel button

ChannelButton, ChannelLayout and Cancel are stated on the same ownership levels as the QrCode section below — the ui_config record → the client (Veriqa:OpenIddict:Clients[]) → this global section — and the nearest level that states a key wins it on its own.

Veriqa:AuthPageDesign:QrCode

The QR code on the sign-in page: whether to show it and at which resolution to draw it.

Key	Default	Meaning
`ShowQrCode`	`DesktopOnly`	Whether the QR is shown: `Always` — on every device; `DesktopOnly` — everywhere but a phone, which gets the channel buttons instead; `Never` — only the channel buttons, on any device
`PixelsPerModule`	`6`	QR resolution — pixels per module; allowed range `5`…`35`
`PixelsPerModuleByChannel`	—	Map “channel type → resolution” of the same level, read before that level’s `PixelsPerModule`; a channel absent from the map takes the `PixelsPerModule` of the same level

The section is stated on three ownership levels, and the nearest level that states it wins: the ui_config record → the client (Veriqa:OpenIddict:Clients[].QrCode) → this global section. Showing the QR and its resolution are two different settings, and a level wins each of them on its own: a client that states only ShowQrCode keeps the global resolution. The resolution itself is ONE setting stated per channel: PixelsPerModuleByChannel and PixelsPerModule are two entries of the same level, and a level exhausts both of them before the lookup moves on to the level below. What that means in practice: a client that states only PixelsPerModule wins the resolution for every channel — the per-channel map of the global section is never reached. To keep a channel’s own resolution, name it in the map of the same level that states PixelsPerModule. An example. The global section states PixelsPerModule: 6 and a PixelsPerModuleByChannel entry telegram: 14, while the app-client client states only PixelsPerModule: 8:

Channel	Resolution for `app-client`
`telegram`	`8` — the client has no map, so its `PixelsPerModule` wins and the global section’s map is never read
`whatsapp`	`8` — for the same reason

A PixelsPerModule outside the range on the client or ui_config level does not apply — the resolution comes from the level below and the host still starts. Such a value is reported by ONE warning in the log per configuration snapshot: the whole catalog of values (the global section, the client entries, the ui_config records) is checked at startup and on every configuration reload, rather than on every request. In the global section such a value remains a deployment error and prevents startup.

Veriqa:Localization and Veriqa:ChannelDisplay

Key	Default	Meaning
`Localization:DefaultLanguage`	`en`	Sign-in page language when the user has no preference
`ChannelDisplay:Mode`	`Multichannel`	How channels are presented
`ChannelDisplay:ChannelOrder`	—	Explicit ordering of channel buttons
`ChannelDisplay:Hints`	—	Map of channel type to hint text. The hint renders inside its own channel’s panel, so with tabs only the selected channel shows one, and with channel buttons it stands under the button of its own channel. The key is the channel type (`whatsapp`, `telegram`, your SPI channel) and its case does not matter; a channel absent from the map, or one with blank text, gets no hint. The text may carry inline markup — `span`, `strong`, `em`, `a`, `br`; a value outside that shape is shown as plain text, with a warning in the log — see Markup in the title, the instruction and a channel hint

Veriqa:RateLimit

Per-endpoint limits, each a permit count over a window in seconds. Defaults:

Endpoint group	Permits / window
`Authorize`	60 / 60s
`Token`	20 / 60s
`Callback`	60 / 60s
`Polling`	600 / 60s
`Webhook`	100 / 60s
`SignalR`	30 / 60s
`EmailStart`	5 / 60s
`UserAuth`	5 / 60s (`UserAuthQueueLimit` 0, `UserAuthMaxPartitions` 50000)

Webhook limits deserve attention when you scale: they apply per instance, and a channel provider that retries aggressively can trip them.

Veriqa:InitiatorContext

Context about the device that started the transaction, shown to the user before they confirm — see Initiator context.

Key	Default	Meaning
`Enabled`	`true`	Collect initiator context at all
`CollectIpAddress`	`true`	Collect the IP address
`CollectUserAgent`	`true`	Collect the user agent
`CollectGeoLocation`	`true`	Resolve geolocation
`StoreRawUserAgent`	`false`	Persist the raw UA string
`DisplayFields`	see concept page	Which fields the confirmation message shows
`AnomalyDetection:Enabled`	`false`	Flag unusual sign-in context
`GeoIp:Provider` / `GeoIp:DatabasePath`	offline	GeoIP source

The offline GeoIP path expects a GeoLite2 database, which Veriqa does not ship. Download it from MaxMind yourself and accept their EULA — the library is Apache-2.0, the license sits on the data. The standalone image already carries the library: mount the database and set GeoIp:DatabasePath to switch it on. In your own host it arrives in the satellite package Veriqa.Core.AuthServer.MaxMind (builder.Services.AddMaxMindGeoIp()).

Veriqa:HopMode

Hop mode puts a short one-time link to your Veriqa server into the QR code instead of the channel link. Two of its settings are set node-wide and may be overridden for a single channel:

Key	Default	Meaning
`Veriqa:HopMode:Enabled`	`false`	Hop mode on for every channel
`Veriqa:HopMode:RedirectStyle`	`Interstitial`	How the hop link leads to the channel: `Interstitial` or `Direct`. The Email channel with the emailed link on answers in its own way — see below
`Veriqa:Channels:{Channel}:HopEnabled`	not set	Overrides `Veriqa:HopMode:Enabled` for this channel
`Veriqa:Channels:{Channel}:HopRedirectStyle`	not set	Overrides `Veriqa:HopMode:RedirectStyle` for this channel

A channel value, when set, wins over the node-wide one; an absent or empty channel value inherits it. The remaining HopMode.* keys and their defaults are listed in Keys in the declaration catalog, where HopMode.Enabled and HopMode.RedirectStyle show “not declared”: their defaults are the values above. One QR code for the whole transaction. Veriqa:HopMode:QrMode decides what a sign-in window or a confirmation page with several channels shows while hop mode is on for at least one of them:

Value	The page shows
`PerChannel`	Tabs, each channel with its own QR code. Default.
`Unified`	One QR code for the whole transaction and the channel buttons beside it, no tabs; the channel is picked on the phone that scans it.
`UnifiedWithChannels`	Both: the first tab, “Any channel”, holds the one QR code and the buttons of every channel; a tab per channel follows with that channel’s own QR code and its button.

A page of one channel, a page under ShowQrCode: Never and a phone under DesktopOnly show no tabs whatever the value. In a desktop window wide enough for it, a page with the single QR code uses two columns — the QR code on the left, the channel buttons on the right; a narrower window, and a page that shows no channel buttons on the desktop (ShowChannelButton: MobileOnly or Never), keep one column. Veriqa:HopMode:ShowChannelButtonsOnAnyChannelTab (default true) decides, under UnifiedWithChannels, whether the “Any channel” tab shows the channel buttons beside the one QR code. With false that tab holds the QR code alone and its instruction asks only to scan it; the tab of each channel keeps its button. A phone under ShowQrCode: DesktopOnly shows no QR code, so it shows the buttons of every channel whatever the value. Under PerChannel and Unified the key has no effect.

We recommend switching hop mode on. It gives the best user experience: a lighter QR code that any phone camera reads at once, a “scanned” signal on the desktop page as soon as the phone opens the link, and a launch page where a direct jump into the messaging app is unreliable. It stays off by default for one reason: every hop link is built on Veriqa:OpenIddict:Server:Issuer, so with hop on the issuer has to be stated as an absolute https address, or the server does not start. The phone also has to reach that address — to try hop mode on your own machine, put Veriqa behind an HTTPS tunnel, see Testing the integration locally. Why hop mode is better is covered in Hop mode.

The Email channel under hop mode. The target of the Email channel is an email the phone itself opens — as it is without hop mode. While the sign-in by an emailed link is on (PullEnabled), the phone gets one page — the address field and the button that opens the email — under either RedirectStyle, and the page never opens the mail client by itself. With the emailed link off, Email follows RedirectStyle like any other channel: Interstitial gives the launch page, which opens the email by itself and keeps a button in case it did not open; Direct redirects straight to the email (302 to mailto:), and that redirect tells the sign-in page that the email is open in the mail app. See Email under hop mode.

Hop mode for one application

The same members can be stated inside the entry of an OIDC client (Veriqa:OpenIddict:Clients), and they then apply to that application only:

Member of the client entry	Meaning
`HopMode:Enabled`	Hop mode for this application, for every channel
`HopMode:RedirectStyle`	How the hop link leads to the channel for this application
`HopMode:QrMode`	`PerChannel`, `Unified` or `UnifiedWithChannels` for this application
`HopMode:ShowChannelButtonsOnAnyChannelTab`	Whether the “Any channel” tab shows the channel buttons for this application
`Channels:{Channel}:HopEnabled`	Overrides `HopMode:Enabled` of the entry for this channel
`Channels:{Channel}:HopRedirectStyle`	Overrides `HopMode:RedirectStyle` of the entry for this channel

appsettings.json

{
  "Veriqa": {
    "OpenIddict": {
      "Clients": [
        {
          "ClientId": "portal",
          "HopMode": { "Enabled": true },
          "Channels": {
            "Email": { "HopEnabled": false }
          }
        }
      ]
    }
  }
}

For each channel the value is taken in this order: the channel value of the client entry → the general value of the client entry → the node (its channel value, then the node-wide one). A client entry that states nothing inherits the node. A value that cannot be read — "HopEnabled": "maybe", or a style name other than Interstitial / Direct — is skipped with a warning in the log, and the next value in that order applies. A style stated as a number that names neither of the two is skipped the same way, but without the warning. The other hop settings — what is collected about the scanning device, TokenLifetime and HopPath — are set for the node only. The endpoint behind the hop link (HopPath) exists only when hop mode is on at startup for a channel that is enabled on the node — node-wide, for that channel, or in at least one client entry. Client entries are read once at startup: if hop mode was off everywhere and you turn it on in a client entry, restart the host. Whenever hop mode is on, Veriqa:OpenIddict:Server:Issuer has to be an absolute https URL — in a client entry as well as on the node.

Infrastructure

Flat keys read by the host, mostly relevant when you run more than one instance or behind a proxy:

Key	Meaning
`Veriqa:SignalR:RedisConnectionString`	SignalR backplane; unset means single-instance
`Veriqa:DataProtection:RedisConnectionString`	DataProtection keys in Redis
`Veriqa:DataProtection:KeysDirectory`	DataProtection keys on disk (a shared volume)
`Veriqa:ChannelStores:Redis:ConnectionString`	Channel stores in Redis, shared by every instance; unset means in-process stores. With the transaction store on `Redis` it must equal `Veriqa:TransactionEngine:Store:ConnectionString`, otherwise the host does not start. See Storage
`Veriqa:ChannelStores:Redis:*`	The other parameters of the channel stores under their own names: `PromptKeyPrefix`, `EmailActionTokenKeyPrefix`, `EmailPushCorrelationKeyPrefix`, `ProcessedMessageKeyPrefix`, `EmailClaimCompletionKeyPrefix`, `PhoneRequestCorrelationKeyPrefix`, `LinkHandleKeyPrefix`, `StartCodeKeyPrefix`, `ProcessedMessageRetention` (`hh:mm:ss`)
`Veriqa:Events:RabbitMq:ConnectionString`	Switches the RabbitMQ event publisher on; unset means no publishing. The other keys of the section: `ExchangeName`, `QueueCapacity`, `MaxReconnectAttempts`, `ReconnectBaseDelaySeconds`. See Storage
`Veriqa:CollectedClaims:Store:Enabled`	Collected claims store, `false` by default: `true` keeps the claims Veriqa collected in the transaction store database and requires `Veriqa:TransactionEngine:Store:ConnectionString` — without it the host does not start. It does not combine with `Veriqa:TransactionEngine:Store:Provider` = `Redis`: Redis has no relational database to hold the claims, and the host does not start either. See Storage
`ForwardedHeaders:KnownProxies` / `:KnownIPNetworks`	Trusted proxies behind TLS termination
`Veriqa:PathBase`	Path prefix the host is deployed under, for example `/auth/veriqa`; unset means the root of the host name. Starts with `/`, does not end with `/`, and has no `?`, `#`, `%`, `\`, whitespace or `.` / `..` segment — another form stops the host at startup. See Behind a reverse proxy

With neither DataProtection option set, keys live in memory and are lost on restart — fine for development, broken for a scaled deployment.

Redis licensing. Redis server ≥ 7.4 ships under RSALv2/SSPL (8.x additionally offers AGPL). That does not affect Veriqa’s license, but if it affects your policy, Valkey (BSD) is a drop-in alternative.

Veriqa:Channels

Every channel lives under Veriqa:Channels:{Channel} and activates only with "Enabled": true. Full setup with the provider-side steps is in Channel setup.

Section	Key settings
`Veriqa:Channels:Telegram`	`BotToken`, `UpdateMode`, `WebhookBaseUrl`, `WebhookSecretToken`, `BotUsername`
`Veriqa:Channels:Max`	`BotToken`, `UpdateMode`, `WebhookBaseUrl`, `WebhookSecretToken`, `BotPublicName`
`Veriqa:Channels:WhatsApp`	`Provider`, `BusinessPhoneNumber`, `MetaCloudApi:`, `Twilio:`
`Veriqa:Channels:Instagram`	`AppSecret`, `WebhookVerifyToken`, `AccessToken`, `AccountId`, `Username`, `GraphApiBaseUrl`, `GraphApiVersion`, `UnaddressedReplyEnabled`
`Veriqa:Channels:Messenger`	`PageId`, `PageName`, `PageAccessToken`, `AppSecret`, `WebhookVerifyToken`, `GraphApiBaseUrl`, `GraphApiVersion`, `UnaddressedReplyEnabled`, `DeepLinkByPageId`
`Veriqa:Channels:WeChat`	`AppId`, `AppSecret`, `Token`, `ApiBaseUrl`
`Veriqa:Channels:Viber`	`AuthToken`, `BotUri`, `SenderName`, `WebhookBaseUrl`, `ApiBaseUrl`
`Veriqa:Channels:Email`	`PublicBaseUrl`, `PullEnabled`, `PushEnabled`, `TokenTtl`, `MailResendInterval`, `Outbound:`, `Inbound:`

Two more keys go into the section of any channel, a channel of a third-party adapter included: SpareStartCodeEnabled (bool, defaults to true) switches the spare start code the sign-in page offers for a channel that keeps a working link, and BotName (text, not set by default) states the name the user sees the chat under — it wins over the name the channel reports. Both are keys of the core with the channel as a dimension, Channels.SpareStartCodeEnabled and Channels.BotName in the catalog, stated in the configuration of the host or for a tenant. What they change on the pages: Channel setup.

InboundVerification — a required key of every channel section

Veriqa:Channels:{Channel}:InboundVerification declares how the authenticity of an incoming event of that channel is verified. The value comes from a closed dictionary:

Value	Meaning
`signature`	The request body is signed with a platform key (HMAC and the like)
`shared_secret`	The incoming request presents a shared secret (a header, a token)
`outbound_fetch`	There are no incoming requests — Veriqa fetches the events with an outgoing request of its own
`none`	The authenticity of an incoming event is not verified

The key is required for every enabled channel. A deployment where a channel declared at core level is enabled ("Enabled": true) and the value is missing or outside the dictionary does not start: the message names the channel type, the address of the key and all four admitted tokens. State the value in the sections of disabled channels too — then flipping Enabled to true does not break startup. The startup check walks exactly the set of channels the core builds its enabled list from: all shipped channels are in it, a channel plugged in through the SPI with a bare AddChannel call is not — the key of its section is needed as well, but a missing value does not prevent startup, see Build a channel adapter in C#.

You declare the fact, not the adapter and not the core: Veriqa only sees that a check ran and passed, never what the check was — and deriving the value from the channel type would leave a third-party channel with nothing to describe it. The value for every built-in channel and mode is in Channel setup. A channel that fetches its updates itself (UpdateMode: Polling) while declaring anything other than outbound_fetch produces a Warning at startup; startup continues. The declared value reaches the audit record as an attribute of its own, so the audit log shows what a confirmation was protected by.

OutcomeNotice — where the receipt of an outcome appears

Veriqa:Channels:OutcomeNotice:DisplayIntent (key Channels.OutcomeNotice.DisplayIntent) says how you want the receipt of a terminal outcome to appear in the conversation. It is stated over three levels — core, tenant and application — and each of them overrides the one below it freely: the global section sets the intent of the whole installation, a tenant states its own with the member OutcomeNoticeDisplayIntent of its record, and a single application with the member of the same name in its OIDC client entry. A ui_config record states no intent. Whatever level answers, the value covers the outcome as a whole — a confirmation, a decline and an expiry are all shown the same way.

Value	What it asks for
`ReplacePrompt`	The receipt takes the place of the message that asked the question: the conversation keeps one message, and the buttons go away with the text they belonged to
`NewMessage`	The receipt arrives as a message of its own; the question stays in the conversation with its wording untouched, and its buttons are taken away where the platform can do that without rewriting the text

The shipped value is ReplacePrompt — what the channels did before the setting existed, so a deployment that states nothing sees no change. An unreadable value is read as nothing stated and answers ReplacePrompt too; startup is not interrupted.

This is an intent, not a guarantee. Telegram and MAX honor it. WhatsApp, Instagram, Messenger, WeChat and Viber always send a new message, and Email shows no outcome receipt at all — as they ship today. An adapter that does not honor the intent is not failing: nothing is logged as an error and the result of the delivery does not change. With NewMessage the receipt arrives as its own message and the buttons of the question are taken away as part of the same delivery, where the platform can change a message’s buttons without rewriting its text; the wording of the question is never rewritten. Failing to take the buttons away is not a failure of the delivery either — and where a button does survive, pressing it only earns another receipt, because a terminal transaction cannot be replayed.

Veriqa:CompletionBehavior

What a channel does after a sign-in is completed. It is one action, stated for every channel at once or for a channel of its own, and — for the actions that show buttons — what those buttons are.

Key	Default	Meaning
`Action`	`None`	The action for every channel that has no entry in `ActionByChannel` of the same level: `None` — nothing is sent after the sign-in; `WelcomeMessage` — the user receives a welcome message in the channel they signed in through; `Menu` — a message with a list of buttons; `Redirect` — a message with one button that opens a link
`ActionByChannel`	—	Map “channel type → action” of the same level, read before that level’s `Action`; the channel type is matched case-insensitively. A channel absent from the map takes the `Action` of the same level
`MenuItems`	`[]`	The buttons of `Menu` for every channel that has no entry in `MenuItemsByChannel` of the same level, in display order. Each item is `{ "Text": "…", "Action": "…" }`. An empty list states nothing
`MenuItemsByChannel`	—	Map “channel type → items” of the same level, read before that level’s `MenuItems`; the channel type is matched case-insensitively
`RedirectUrl`	not set	The address of the `Redirect` button for every channel that has no entry in `RedirectUrlByChannel` of the same level: an absolute URL written as `scheme://…`. May carry the `{handle}` placeholder — a link handle
`RedirectUrlByChannel`	—	Map “channel type → address” of the same level, read before that level’s `RedirectUrl`; the channel type is matched case-insensitively
`RedirectButtonText`	`Open`	The label of the `Redirect` button — one for every channel

The action is stated on three ownership levels, and the nearest level that states it wins: the client → the tenant → this global section. Above the global section the same members sit in the CompletionBehavior section of the level’s own record — for an application that is Veriqa:OpenIddict:Clients[].CompletionBehavior:Action and …:ActionByChannel. A ui_config record states no action: this is behavior, not presentation. The shipped value is None, so a deployment that states nothing sees no change. A value the setting does not accept never interrupts startup, and how far it reaches depends on its shape. A text that is not one of the names of the setting — in Action or in an entry of ActionByChannel — leaves the whole level unstated: neither member of that level is read, and the action comes from the level below. A number that names no action discards only the entry it stands in: with Action: "WelcomeMessage" and ActionByChannel: { "telegram": 7 } on one level, telegram takes that level’s WelcomeMessage. The action is ONE setting stated per channel: ActionByChannel and Action are two entries of the same level, and a level exhausts both of them before the lookup moves on to the level below. So a client that states only Action wins the action for every channel — the per-channel map of the global section is never reached. To keep a channel’s own action, name it in the map of the same level that states Action.

{
  "Veriqa": {
    "CompletionBehavior": {
      "Action": "None",
      "ActionByChannel": { "telegram": "WelcomeMessage" }
    }
  }
}

Here a sign-in through telegram is followed by a welcome message, and a sign-in through any other channel by nothing. What a channel performs is a fact of the channel, not of your configuration:

Channel type	Actions the channel performs
`telegram`, `max`	`None`, `WelcomeMessage`, `Menu`, `Redirect`
`whatsapp`	`None`, `WelcomeMessage`
`email`	`None`
a channel that declares nothing — a custom SPI adapter, a channel connected over HTTP	`None`

An action the channel does not perform is never handed to it. It is replaced by the channel’s own default — None for every channel in the table — and the replacement is loud: a Warning in the log and an audit event channel_completion_behavior_clamped whose details read requested=<action>; applied=<action>. The sign-in itself completes as usual. The audit record names the tenant and the client of the sign-in — the levels the action may have been stated on — and, as its actor, the masked channel user. It carries the failure outcome, as every channel event does, although the sign-in succeeded. None is never replaced: doing nothing is honored on every channel, silently. Menu and Redirect send one message: a text with buttons under it. Redirect is a single button that opens a link; Menu is a list of buttons, one in a row, in the order you state them. The channels that perform them are in the table above; on any other channel the action is replaced, as described there.

{
  "Veriqa": {
    "CompletionBehavior": {
      "Action": "None",
      "ActionByChannel": { "telegram": "Menu" },
      "MenuItems": [
        { "Text": "Open the app", "Action": "https://app.example.com/home" },
        { "Text": "My orders", "Action": "orders" }
      ]
    }
  }
}

Here a sign-in through telegram is followed by a menu of two buttons: the first opens a link, the second is handed to your code. A redirect needs the address only — the label ships as Open:

{
  "Veriqa": {
    "CompletionBehavior": {
      "ActionByChannel": { "telegram": "Redirect" },
      "RedirectUrl": "https://app.example.com/home"
    }
  }
}

The items and the address are stated like the action. MenuItems and RedirectUrl live on the same three levels, each next to its own per-channel map, and a level exhausts its map and its plain member before the level below is read — so a client that states only RedirectUrl wins the address for every channel. RedirectButtonText is one value per level, with no per-channel map. A ui_config record states none of them. The labels are translated, the address is not touched. Text of an item and RedirectButtonText are looked up in the locale files of your host in the language of the recipient; a label no file carries is shown as you wrote it. The address is sent exactly as stated: nothing about the user is substituted into it. The text above the buttons is a message of its own — the kind post-login-menu or post-login-redirect, worded and overridden like any other message: Veriqa:MessageTemplates. What makes an item a link. An Action written as an absolute URL with scheme:// in front — https://…, tg://… — becomes a link button. Any other value is callback data: the button sends it back when pressed. The rule is the same one RedirectUrl is checked by. An address without // — mailto:…, tel:… — is therefore read as callback data, not as a link. A value with a space or a line break at either edge is not accepted at all — neither as RedirectUrl nor as an Action: it is reported like any other value outside the setting’s domain, and an item written that way takes its whole list with it. Whether a scheme is allowed on a button is the platform’s decision: an address it refuses fails the send, and the message does not go out. A link can carry a link handle. Write {handle} — in exactly this case — into RedirectUrl, an entry of RedirectUrlByChannel or the Action of a link item, for example https://t.me/shop_bot?start={handle}. When the message is sent, every {handle} in its addresses is replaced by one single-use value of 22 characters [0-9A-Za-z]; your server exchanges it for the identity of the user who signed in — Two bots. One message carries one handle, valid for Veriqa:TransactionEngine:CompletedRetentionSeconds from the moment it is issued. An address without the placeholder is sent as written and no handle is issued; there is no separate setting to switch this on. In callback data {handle} is not replaced — the value goes out as written. If the handle cannot be issued — the sign-in belongs to no client, or the handle store refused the record — the buttons that ask for it are not sent and a Warning is written: Redirect sends nothing, Menu goes out without those items. The sign-in is not affected. A callback item is handed to your code. The press reaches the built-in channel adapter — the bot is yours and Veriqa runs in the same process — and is passed to the handler you register:

builder.Services.AddScoped<IMenuItemPressHandler, OrdersMenuHandler>();

public sealed class OrdersMenuHandler : IMenuItemPressHandler
{
    public Task HandleAsync(MenuItemPress press, CancellationToken cancellationToken = default)
    {
        // press.ChannelType, press.ChannelUserId, press.TenantId (null — the default tenant),
        // press.Value — the value the pressed button carried: the Action of the item
        // as it was stated when the message was sent. Check it before acting on it.
        return Task.CompletedTask;
    }
}

IMenuItemPressHandler and MenuItemPress come with the Veriqa.Core.Contracts package. The handler returns nothing: Veriqa has already acknowledged the press to the platform, and what it means is up to you. The event names no sign-in — the menu is shown after the sign-in is over. The handler is created when an item is pressed, in the scope of that event, and for no other event of the channel. An exception — thrown by its constructor or by HandleAsync — is logged and affects neither the user nor any sign-in. Return quickly. HandleAsync is awaited while the event is being processed. Until it returns the platform is not told that the event was received: a webhook left unanswered is delivered again, and your handler gets the same press twice; in polling mode the events of other users wait behind it. Put anything slow into a background queue of your own and return. Treat press.Value as untrusted input. A button outlives the configuration that drew it: an item you removed from MenuItems can still be pressed in an old message, and Veriqa does not check the value against the items configured today. Check the value, and what this user may do, in your handler. Without a registered handler callback items are not drawn. A Warning names how many were left out; the link items of the same menu are still sent. A press of a button sent before a restart that dropped the handler is left without processing. When nothing is sent. Menu with no items stated for the channel, Menu whose every item was left out, and Redirect with no address stated each write a Warning and send nothing; the sign-in completes as usual. A value the setting does not accept never interrupts startup and leaves its entry unstated, so the value comes from the next entry or the level below: a RedirectUrl that is not a URL, and a list in which any item has a blank Text or Action — one such item takes the whole list of that entry out. An empty list states nothing either: to switch a menu off on a level above, state the Action, not an empty list. The platform’s budget is checked before the send, by the limits the platform itself names:

Channel type	Checked before the send	What happens over the limit
`telegram`	the payload of a callback button — 64 bytes in UTF-8, the marker `vq_menu_` included, which leaves 56 bytes for your `Action`	that button is left out with a `Warning`; the rest are sent
`max`	the address of a link button — 2048 characters. The platform names no limit for the payload of a callback button, so nothing is checked beforehand	a link button over the limit is left out with a `Warning`. A callback value the platform refuses fails the send: the whole message does not go out, not one button

A message none of whose buttons can be drawn is not sent. How a post-completion message behaves — the welcome message and a message with buttons alike:

It follows every completed sign-in of a channel that performs the action — confirmed in the channel, confirmed on the web page, or completed by the steps that collect missing claims. A confirmation your server creates is not a sign-in and is followed by nothing.
It arrives as a message of its own, after the outcome receipt, and never replaces it.
A failure to send it is logged and does not change the result of the sign-in.
The text of the welcome is the message kind post-login-welcome — worded, localized and overridden like any other message: Veriqa:MessageTemplates.
Delivery is not recorded on the transaction. An event repeated in order earns no second message; the same event processed twice at the same moment may, as the product ships today.

In the catalog table the key CompletionBehavior.Action shows not declared in the Default column: the shipped None is applied where no level states the action, the same way as the shipped resolution of AuthPageDesign.QrCode.PixelsPerModule. CompletionBehavior.MenuItems and CompletionBehavior.RedirectUrl show not declared for a plainer reason: the product ships no menu and no address.

Veriqa:MessageTemplates

Everything the user reads in the messaging app and in email is a message. One message is two settings rather than one text: the contract declares which slots the message has, and the template carries the wordings that use those slots. Hence two addresses — one pair per message, not one line per text:

Setting	Address on the `Core` level
Contract	`Veriqa:MessageTemplates:{kind}:[ByType:{transaction type}]:[ByAction:{action type}]:Contract`
Template	`Veriqa:MessageTemplates:{kind}:[ByType:{transaction type}]:[ByAction:{action type}]:[BySurface:{surface}]:[ByChannel:{channel}]:Templates`

The bracketed groups are optional: a wording that does not narrow along an axis drops that group whole — which is how one address serves every step of the lookup, from the most specific ({kind, transaction type, action type, surface, channel}) down to the broadest ({kind}). The kind never drops out: “the text of which message” is the question itself. One group is not independent: ByAction is read only under ByType. No step of the lookup names an action type without its transaction type, so a wording at {kind}:ByAction:{action type} would never be reached — the host refuses to start on it, saying the address is “narrowed by a combination of axes no step of its ladder addresses”. A confirmation’s action type is therefore worded at {kind}:ByType:confirmation:ByAction:{action type}. The kinds the product ships:

Kind	What it is
`confirmation-prompt`	the sign-in confirmation request a channel shows to the user
`sign-in-mail`	the Email channel’s sign-in email: its subject and its body
`claim-code-mail`	the email with a code that confirms an email address the user entered on the web step of the claims completion
`claim-link-mail`	the email with a link that confirms an email address the user entered on the web step of the claims completion
`claim-code-link-mail`	the email with both a code and a link, sent when the list of ways names `Code` and `MagicLink` together; the address is confirmed by whichever the user does first
`deeplink-prefill`	the pre-filled message the user sends themselves (WhatsApp, Email Push)
`phone-number-request`	the text of the request for a phone number the user may skip (`Optional`), which the claims completion sends into the user’s chat; the labels of its buttons are not part of the message
`phone-number-request-required`	the same request for a phone number the sign-in cannot finish without (`Required`); a wording stated for one of the two kinds does not answer for the other
`web-confirmation-notice`	the message a channel sends into the user’s chat once a sign-in or a confirmation has started under `OnWebPage`, to send the user to the Veriqa page where the question is asked; sent once per transaction, by the channels that send messages into the chat (Email does not). Ships two wordings: `Sign-in started — confirm it on the sign-in page` at the bare kind and `Confirmation started — confirm it on the confirmation page` at `ByType:confirmation`, so a wording you state at the bare kind applies to sign-ins only — state one at `ByType:confirmation` too
`outcome-receipt-confirmed`	the outcome receipt for a confirmed decision — the terminal text a transaction answers with
`outcome-receipt-declined`	the outcome receipt for a declined decision
`outcome-receipt-expired`	the outcome receipt for an expired transaction
`outcome-receipt-awaiting-claims`	the state a channel shows while a confirmed sign-in waits for the claims completion; it is not a terminal receipt — the receipt of the outcome follows as a message of its own. Ships one wording, at the bare kind: `Sign-in confirmed. One step left: provide the requested details to finish.`
`post-login-welcome`	the welcome message a channel sends after a completed sign-in, when `Veriqa:CompletionBehavior` asks for one
`post-login-menu`	the text above the buttons of the menu a channel sends after a completed sign-in, when `Veriqa:CompletionBehavior` resolves to `Menu`
`post-login-redirect`	the text above the link button a channel sends after a completed sign-in, when `Veriqa:CompletionBehavior` resolves to `Redirect`

A template’s value is a ladder of steps, fullest to minimal, as one array. A step is either a string (a text that suits any sink) or a structure { "Subject": "…", "Html": "…", "Plain": "…" }, where Html and Plain are the editions of the step: an email is composed once and carries both of its parts at once. Each edition is optional, but a step must state at least one — otherwise startup fails, naming the message kind and the number of the step. The one shown is the first step that states the edition asked for and has all of its slots filled, so the two parts of one email may come from different steps, and the subject is taken from the step chosen for Html. An edition no step states is one the email does not carry at all — that is how an HTML-only email is declared. The minimal step must lean on guaranteed slots only — checked at startup, on every step and for every edition separately. A declaration replaces the ladder whole: the steps stated at different addresses are never merged. A wording the product ships may sit at a narrower address than the one you write. The lookup goes level by level, and a level exhausts every step of the address — from the most specific down to the broadest — before the resolution drops to the level below. The shipped declarations are the fallback of the Core level, read at the same addresses; and Veriqa:MessageTemplates in your appsettings.json is that level. So a declaration of yours placed at a broader address than the shipped one is never reached: the narrower step answers first, and it answers from the product. Nothing fails and nothing is logged — your configuration is valid, it is simply never asked for. (A record above the core is a different level and is read before it, so a wording in a client entry is not shadowed this way — but it applies to that client alone.) The outcome receipts are where this is met first. Each of the three terminal kinds ships a wording at the bare {kind} and narrower ones for a sign-in:

Shipped address of `outcome-receipt-confirmed`	Text
`outcome-receipt-confirmed:Templates`	`Confirmed ✅`
`…:ByType:login:BySurface:in-channel-messenger:Templates`	`Sign-in confirmed ✅`
`…:ByType:login:BySurface:in-channel-messenger:ByDevice:mobile:Templates` and `…:ByDevice:tablet:Templates`	`Sign-in confirmed ✅ Tap Back to return to the sign-in page.`
`…:ByType:login:BySurface:in-channel-plain:Templates`	`Sign-in confirmed`
`…:ByType:login:BySurface:in-channel-plain:ByDevice:mobile:Templates` and `…:ByDevice:tablet:Templates`	`Sign-in confirmed. Tap Back to return to the sign-in page.`
`…:ByType:login:BySurface:email-confirm-page:Templates`	`Sign-in confirmed! You can close this tab.`

outcome-receipt-declined ships the four addresses without ByDevice; outcome-receipt-expired ships those four plus a step at ByType:login. A receipt of a sign-in shown in a messaging app asks about {kind, login, in-channel-messenger} — and about the channel, which no shipped receipt narrows by, and about the device the sign-in was started on — so restating outcome-receipt-confirmed:Templates changes nothing there. Word it at the same addresses the product used, the two device steps included:

appsettings.json

{
  "Veriqa": {
    "MessageTemplates": {
      "outcome-receipt-confirmed": {
        "Contract": {
          "Slots": [ { "Name": "app", "Type": "string", "Source": "ServerInitiatorContext" } ]
        },
        "ByType": {
          "login": {
            "BySurface": {
              "in-channel-messenger": {
                "Templates": [ "Signed in to {app} ✅", "Signed in ✅" ],
                "ByDevice": {
                  "mobile": { "Templates": [ "Signed in to {app} ✅ Tap Back to return.", "Signed in ✅ Tap Back to return." ] },
                  "tablet": { "Templates": [ "Signed in to {app} ✅ Tap Back to return.", "Signed in ✅ Tap Back to return." ] }
                }
              }
            }
          }
        }
      }
    }
  }
}

A sign-in started on a phone or a tablet gets a receipt of its own. The button of the channel opens the app on the same device, so the receipt tells the user how to get back to the sign-in page; a sign-in started on a computer keeps the short text. The device steps are the reason the example above states ByDevice: in the configuration of the host a shipped step that names the device is asked before your step at the same address without it, so a declaration of …:in-channel-messenger:Templates alone leaves phones and tablets with the shipped Sign-in confirmed ✅ Tap Back to return to the sign-in page.. A declaration in a client entry, a tenant record or a ui_config record is a level above the core and answers whole — no shipped step is reached from there. The contract stays at the root of the kind — it narrows by the transaction type and the action type and never by the surface — and the ladder ends with a step using no slot, because no slot of a receipt is guaranteed (below). A receipt of a confirmation is a different address: the shipped file states nothing under ByType:confirmation, so there the broad {kind} declaration is the step that answers and rewording it works as written. Veriqa does not know the device a confirmation is answered on, so the device steps never apply to it. If you want the receipt to tell the user how to get back to your page, word it yourself with a caller slot whose value you pass in slot_values when you create the confirmation (below). The surfaces a receipt is addressed with are in-channel-messenger (a channel that renders emoji — the messaging apps the product ships an adapter for, and any channel declaring as much of itself), in-channel-plain (a channel that does not), email-confirm-page (the confirmation page of the Email channel), core-page (the confirmation page Veriqa serves itself) and interaction-page (the page a confirmation with no browser callback leaves the user on). Outcome receipts are plain text only. All four outcome-receipt-* kinds ship with one edition — Plain — and the general rule “an edition no step states is one the email does not carry” does not apply to them: a receipt has a single part, and not showing it means not answering the user at all. So a receipt ladder overridden with the Html edition only yields no text whatsoever — that is a broken installation rather than a different look: the render fails, naming the message kind, and no other edition is substituted for it. Escaping a receipt on its way into a page is the page’s job, so plain text takes nothing away from your wording. A receipt can name what was confirmed. The shipped contract of the three receipt kinds declares no slots, so the shipped receipts say nothing about the action. Declare caller slots in the contract of a receipt on your level — under ByType:confirmation:ByAction:{action type} to word it per action — and the receipt is filled from the slot_values the confirmation was created with, by the same names. A caller slot of a receipt states MaxLength, as it does in the question:

"outcome-receipt-confirmed": {
  "ByType": {
    "confirmation": {
      "ByAction": {
        "purchase-title": {
          "Contract": {
            "Slots": [ { "Name": "title", "Type": "string", "MaxLength": 64 } ]
          },
          "Templates": [ "Purchase confirmed: “{title}” ✅", "Purchase confirmed ✅" ]
        }
      }
    }
  }
}

A value the transaction does not carry (a sign-in, a confirmation created without it) leaves the step that uses it out, and the next step answers — so the minimal step of a receipt never counts a caller slot as guaranteed, even one marked Required. A receipt answering a decision from a channel the question was never shown in gets no caller values, and neither does a receipt on the entry page of a confirmation unless InteractionPage is in ConfirmationSubjectDisplay.Surfaces. The server slots described below are filled there all the same, except outcome_at on the entry page. A receipt can also carry what the product knows about the transaction. Its contract may declare the server slots app, browser, os, region (type string, Source: ServerInitiatorContext) and outcome_at (type datetime, Source: ServerSystem); a caller value never fills them. Naming one of those five Source: Caller instead is not refused at startup, but it does not hand you the slot: app is always the product’s, and the other four are yours only on the branches where the product has no value of its own. Use a name of your own instead. app names the application: the client_id of a confirmation, the client’s display name (or its client_id) for a sign-in. browser, os and region come from the initiator context, so only a sign-in has them, and they obey the same Enabled and DisplayFields of Veriqa:InitiatorContext as the sign-in prompt. outcome_at is the moment of the decision, or the deadline of an expired transaction; the entry page words its receipts before the outcome, so there it has no value. None of these slots is guaranteed in a receipt, even one marked Guaranteed, so the minimal step cannot rest on them. The welcome message greets the user by name. The kind post-login-welcome is the text sent when Veriqa:CompletionBehavior resolves to WelcomeMessage. Its shipped contract declares one slot — name (type string, Source: ServerIdentityClaims), filled from the name claim of the identity the sign-in resolved — and its shipped ladder has two steps:

"post-login-welcome": {
  "Contract": {
    "Slots": [ { "Name": "name", "Type": "string", "Source": "ServerIdentityClaims" } ]
  },
  "Templates": [ "Welcome, {name}! You are signed in.", "Welcome! You are signed in." ]
}

A channel that gave no name leaves the first step out, and the second answers. The message is sent as plain text and in the language of the recipient — the one the channel reported, otherwise the language of the page the sign-in started on. name is the only claim a slot is filled from as the product ships today: a slot of the same source under another name gets no value, so a step that uses it is always left out. Word the message per channel under post-login-welcome:BySurface:in-channel:ByChannel:{channel}:Templates. The levels of the two settings differ. The contract resolves from Tenant, Application and Core; the template from those plus a ui_config record. So a record selected by a request parameter can pick which of your wordings a user sees, yet can neither widen the slot list nor introduce an action type of its own.

The Tenant level. No reader for the Tenant level is registered out of the box — the integrator writes one. Without it the resolution goes to Application/Core.

The Application level is the client entry. Above the core the address is relative to the record of the level, and the record of Application is the entry of the client in Veriqa:OpenIddict:Clients: the contract of a message for one application sits at Veriqa:OpenIddict:Clients:[n]:MessageTemplates:{kind}:…:Contract. Action types of confirmations your server creates are message kinds of their own, and they are declared only above the core — in the client entry, as MessageTemplates:{action type} with a Contract and Templates. A kind visible only in the host section Veriqa:MessageTemplates is refused by POST /api/transaction/confirmation with action_type_unknown. A complete example with the request and the answer: Server-to-server confirmation API. The device_type axis refines any step. Its value is the type of the device the transaction was started on, as the initiator context states it — desktop, mobile, tablet or unknown — and its group, ByDevice, is the innermost one: it stands under whichever node the rest of the address names, the bare {kind} included, and needs no surface. A step that names the device is asked immediately before the same step without it, so a wording without ByDevice keeps answering for every device no wording was stated for. Only the receipts are asked about the device today; a transaction with no initiator context — it is switched off, or the device type is not collected — is asked about without it. The contract of a message does not narrow by the device. The channel axis refines the surface, so it never appears without surface. The product ships six values along it — both wordings of the pre-filled message, under deeplink-prefill:BySurface:in-channel:ByChannel:whatsapp and …:ByChannel:email, and the request for the phone number in Instagram and in Messenger, under phone-number-request:BySurface:in-channel:ByChannel:instagram and …:ByChannel:messenger and at the same two addresses of phone-number-request-required; the other kinds state no value along this axis, and a step without a channel answers for every channel at once. Asking a key about an axis it does not declare is an error. Wording a message for one channel therefore takes the surface as well. The request for the phone number is the plain case: phone-number-request ships Share your phone number at the bare {kind} and a wording for each of two channels — Instagram and Messenger, which adds what to do without a number in the profile (phone number) — and it is asked about with the surface in-channel and the channel of the sign-in. The request for a Required number is the kind phone-number-request-required, shipped and addressed the same way. A wording for one channel sits at Veriqa:MessageTemplates:phone-number-request:BySurface:in-channel:ByChannel:{channel}:Templates:

appsettings.json

{
  "Veriqa": {
    "MessageTemplates": {
      "phone-number-request": {
        "BySurface": {
          "in-channel": {
            "ByChannel": {
              "telegram": {
                "Templates": [ "Tap the button below to share your phone number" ]
              }
            }
          }
        }
      }
    }
  }
}

The other channels keep their shipped text. The same address in a client entry words the request for one application. The shipped contract of the kind declares no slots, so a wording that uses one needs a contract of yours at phone-number-request:Contract; the request fills the server slots app, browser, os and region from the transaction, by the rules described for the receipts above, and never a caller slot. End the ladder with a step that uses no slot: browser, os and region may have no value, a caller slot of this kind never has one, and marking a slot Guaranteed or Required does not change that. The text is rendered as plain text and translated into the user’s language like any other wording.

Health endpoints

Endpoint	Purpose
`/health/live`	Liveness — the process is up
`/health/ready`	Readiness — configured dependencies answer

Readiness registers a check per configured dependency, so it reflects exactly what you wired up: no database configured means no database check. The remaining endpoints, the metrics and the traces: Observability.

Keys in the declaration catalog

The table below is built from the declaration catalog of keys: the name, the value type, the levels, the dimensions and the address on every level. The remaining keys are described in the sections above. The keys below are the ones Veriqa owns. The same catalog is open to what you ship: an extension of your own declares its keys on the core, application and ui_config levels through the same public API, and its declarations join this schema at startup — see Declare your own configuration keys. The “Default” column prints what the owner of the key declared: what the core level answers when its record states nothing. For a key that declares no such answer, the column says so outright — its defaults live in the sections above. “Declared, value not printed” stands where an answer is declared and has no text to it: the declared answer is null, or the key is declared secret — the schema of a secret key carries the fact of the answer and never its text. What an installation put into a setting is in no column of this table: what is printed here is a declaration, not a resolution.

Key	Value type	Levels	Dimensions	Address per level	Default	Secret
`AuthPage.Instruction`	`string`	UiConfig	—	UiConfig: `instruction`	not declared	no
`AuthPage.Texts`	`CorePageTextOverride`	UiConfig · Application · Tenant	`text`	UiConfig: `texts:{text}` Application: `AuthPage:Texts:{text}` Tenant: `AuthPage:Texts:{text}`	not declared	no
`AuthPage.Title`	`string`	UiConfig	—	UiConfig: `title`	not declared	no
`AuthPageDesign.BrandName`	`string`	UiConfig · Application · Tenant · Core	—	UiConfig: `brand_name` Application: `BrandName` Tenant: `BrandName` Core: `Veriqa:AuthPageDesign:BrandName`	not declared	no
`AuthPageDesign.Cancel.Enabled`	`bool`	UiConfig · Application · Tenant · Core	—	UiConfig: `cancel:enabled` Application: `Cancel:Enabled` Tenant: `Cancel:Enabled` Core: `Veriqa:AuthPageDesign:Cancel:Enabled`	`true`	no
`AuthPageDesign.ChannelButton.ShowChannelButton`	`ChannelButtonVisibility`	UiConfig · Application · Tenant · Core	—	UiConfig: `channel_button:show_channel_button` Application: `ChannelButton:ShowChannelButton` Tenant: `ChannelButton:ShowChannelButton` Core: `Veriqa:AuthPageDesign:ChannelButton:ShowChannelButton`	`Always`	no
`AuthPageDesign.ChannelLayout`	`ChannelLayout`	UiConfig · Application · Tenant · Core	—	UiConfig: `channel_layout` Application: `ChannelLayout` Tenant: `ChannelLayout` Core: `Veriqa:AuthPageDesign:ChannelLayout`	`Tabs`	no
`AuthPageDesign.CustomCss`	`CorePageCustomResource`	UiConfig · Application · Core	—	UiConfig: `custom_css_path` Application: `CustomCssPath` Core: `Veriqa:AuthPageDesign:CustomCssPath`	not declared	no
`AuthPageDesign.CustomJs`	`CorePageCustomResource`	Application (behind a gate) · Core	—	Application: `CustomJsPath` Core: `Veriqa:AuthPageDesign:CustomJsPath`	not declared	no
`AuthPageDesign.FooterHtml`	`string`	Application · Tenant · Core	—	Application: `FooterHtml` Tenant: `FooterHtml` Core: `Veriqa:AuthPageDesign:FooterHtml`	not declared	no
`AuthPageDesign.HopInstructionHtml`	`string`	Application · Tenant · Core	—	Application: `HopInstructionHtml` Tenant: `HopInstructionHtml` Core: `Veriqa:AuthPageDesign:HopInstructionHtml`	not declared	no
`AuthPageDesign.LogoUrl`	`string`	UiConfig · Application · Tenant · Core	`theme`	UiConfig: `logo_url` Application: `LogoUrl` Tenant: `LogoUrl` Core: `Veriqa:AuthPageDesign:LogoUrl`	not declared	no
`AuthPageDesign.Preset`	`DesignPreset`	UiConfig · Core	—	UiConfig: `preset` Core: `Veriqa:AuthPageDesign:Preset`	`Default`	no
`AuthPageDesign.PrimaryColor`	`string`	UiConfig · Application · Core	`theme`	UiConfig: `primary_color` Application: `PrimaryColor` Core: `Veriqa:AuthPageDesign:PrimaryColor`	not declared	no
`AuthPageDesign.QrCode.PixelsPerModule`	`int`	UiConfig · Application · Tenant · Core	`channel`	UiConfig: `qr_code:pixels_per_module` Application: `QrCode:PixelsPerModule` Tenant: `QrCode:PixelsPerModule` Core: `Veriqa:AuthPageDesign:QrCode:PixelsPerModule`	not declared	no
`AuthPageDesign.QrCode.ShowQrCode`	`QrCodeVisibility`	UiConfig · Application · Tenant · Core	—	UiConfig: `qr_code:show_qr_code` Application: `QrCode:ShowQrCode` Tenant: `QrCode:ShowQrCode` Core: `Veriqa:AuthPageDesign:QrCode:ShowQrCode`	`DesktopOnly`	no
`AuthPageDesign.SignalRClientPath`	`string`	UiConfig · Core	—	UiConfig: `signalr_client_path` Core: `Veriqa:AuthPageDesign:SignalRClientPath`	not declared	no
`AuthPageDesign.Theme`	`AuthPageTheme`	UiConfig · Core	—	UiConfig: `theme` Core: `Veriqa:AuthPageDesign:Theme`	`Auto`	no
`ChannelDisplay.Channels`	`IReadOnlyList`1`	UiConfig	—	UiConfig: `channels`	not declared	no
`ChannelDisplay.Hints`	`string`	Core	`channel`	Core: `Veriqa:ChannelDisplay:Hints:{channel}`	not declared	no
`ChannelDisplay.Mode`	`ChannelDisplayMode`	UiConfig · Core	—	UiConfig: `channel_display_mode` Core: `Veriqa:ChannelDisplay:Mode`	`Multichannel`	no
`Channels.BotName`	`string`	Tenant · Core	`channel`	Tenant: no path Core: `Veriqa:Channels:{channel}:BotName`	not declared	no
`Channels.Enabled`	`IReadOnlyCollection`1`	Tenant · Core	—	Tenant: no path Core: no path	not declared	no
`Channels.HealthProbeInterval`	`TimeSpan`	Core	`channel`	Core: `Veriqa:Channels:{channel}:HealthProbeInterval`	`00:00:15`	no
`Channels.Http.AdapterSettings`	`string`	Tenant · Core	`channel`	Tenant: no path Core: `Veriqa:Channels:{channel}:Http:AdapterSettings`	not declared	yes
`Channels.Http.AllowInsecureHttp`	`bool`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:AllowInsecureHttp`	`false`	no
`Channels.Http.BaseUrl`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:BaseUrl`	not declared	no
`Channels.Http.Capabilities.CodeStart.LinkCarriesTransaction`	`bool?`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:CodeStart:LinkCarriesTransaction`	not declared	no
`Channels.Http.Capabilities.CodeStart.MessageTemplate`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:CodeStart:MessageTemplate`	not declared	no
`Channels.Http.Capabilities.DeliversOutcomeNotice`	`bool`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:DeliversOutcomeNotice`	`false`	no
`Channels.Http.Capabilities.PhoneNumber.Acquisition`	`IReadOnlyList`1`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:PhoneNumber:Acquisition`	`[]`	no
`Channels.Http.Capabilities.PhoneNumber.Proof`	`PhoneNumberProof`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:PhoneNumber:Proof`	`NotProven`	no
`Channels.Http.Capabilities.ProvidesRecipientLocale`	`bool`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:ProvidesRecipientLocale`	`false`	no
`Channels.Http.Capabilities.RendersEmoji`	`bool?`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:RendersEmoji`	not declared	no
`Channels.Http.Capabilities.SupportedMessageKinds`	`IReadOnlyList`1`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:SupportedMessageKinds`	`[plain_text]`	no
`Channels.Http.Capabilities.SupportsInChannelConfirmation`	`bool`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:SupportsInChannelConfirmation`	`false`	no
`Channels.Http.Capabilities.SupportsMessageUpdate`	`bool`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Capabilities:SupportsMessageUpdate`	`false`	no
`Channels.Http.DeepLinkSchemes`	`IReadOnlyList`1`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:DeepLinkSchemes`	`[]`	no
`Channels.Http.DeepLinkTimeout`	`TimeSpan`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:DeepLinkTimeout`	`00:00:02`	no
`Channels.Http.DisplayName`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:DisplayName`	not declared	no
`Channels.Http.ErrorMessageText`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:ErrorMessageText`	`Something went wrong. Go back to the sign-in page and start again.`	no
`Channels.Http.IconSvgPath`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:IconSvgPath`	not declared	no
`Channels.Http.OperationTimeout`	`TimeSpan`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:OperationTimeout`	`00:00:10`	no
`Channels.Http.PreviousTransportSecret`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:PreviousTransportSecret`	not declared	yes
`Channels.Http.RetryBudget`	`TimeSpan`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:RetryBudget`	`00:00:20`	no
`Channels.Http.StaleLinkReplyText`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:StaleLinkReplyText`	not declared	no
`Channels.Http.Tenant`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:Tenant`	not declared	no
`Channels.Http.TransportSecret`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:TransportSecret`	not declared	yes
`Channels.Http.UnaddressedReplyText`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:UnaddressedReplyText`	not declared	no
`Channels.Http.UnmatchedCodeReplyText`	`string`	Core	`channel`	Core: `Veriqa:Channels:{channel}:Http:UnmatchedCodeReplyText`	not declared	no
`Channels.InboundVerification`	`ChannelInboundVerification?`	Tenant · Core	`channel`	Tenant: no path Core: `Veriqa:Channels:{channel}:InboundVerification`	not declared	no
`Channels.OutcomeNotice.DisplayIntent`	`OutcomeNoticeDisplayIntent`	Application · Tenant · Core	—	Application: `OutcomeNoticeDisplayIntent` Tenant: `OutcomeNoticeDisplayIntent` Core: `Veriqa:Channels:OutcomeNotice:DisplayIntent`	`ReplacePrompt`	no
`Channels.SpareStartCodeEnabled`	`bool`	Tenant · Core	`channel`	Tenant: no path Core: `Veriqa:Channels:{channel}:SpareStartCodeEnabled`	`true`	no
`Channels.email.Credentials`	`EmailTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.instagram.Credentials`	`InstagramTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.instagram.UnaddressedReplyEnabled`	`bool`	Tenant · Core	—	Tenant: no path Core: `Veriqa:Channels:Instagram:UnaddressedReplyEnabled`	`true`	no
`Channels.max.Credentials`	`MaxTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.messenger.Credentials`	`MessengerTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.messenger.DeepLinkByPageId`	`bool`	Tenant · Core	—	Tenant: no path Core: `Veriqa:Channels:Messenger:DeepLinkByPageId`	`false`	no
`Channels.messenger.UnaddressedReplyEnabled`	`bool`	Tenant · Core	—	Tenant: no path Core: `Veriqa:Channels:Messenger:UnaddressedReplyEnabled`	`true`	no
`Channels.telegram.Credentials`	`TelegramTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.viber.Credentials`	`ViberTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.wechat.Credentials`	`WeChatTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`Channels.whatsapp.Credentials`	`WhatsAppTenantCredentials`	Tenant · Core	—	Tenant: no path Core: no path	not declared	yes
`ClaimCompletion.CollectedClaimsRetentionDays`	`int`	Tenant · Core	—	Tenant: `ClaimCompletionCollectedClaimsRetentionDays` Core: `Veriqa:ClaimCompletion:CollectedClaims:RetentionDays`	`0`	no
`ClaimCompletion.EmailCodeAttempts`	`int`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailLimits:CodeAttempts` Tenant: `ClaimCompletionEmailLimits:CodeAttempts` Core: `Veriqa:ClaimCompletion:EmailLimits:CodeAttempts`	`5`	no
`ClaimCompletion.EmailMailsPerAddress`	`int`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailLimits:MailsPerAddress` Tenant: `ClaimCompletionEmailLimits:MailsPerAddress` Core: `Veriqa:ClaimCompletion:EmailLimits:MailsPerAddress`	`5`	no
`ClaimCompletion.EmailMailsPerDomain`	`int`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailLimits:MailsPerDomain` Tenant: `ClaimCompletionEmailLimits:MailsPerDomain` Core: `Veriqa:ClaimCompletion:EmailLimits:MailsPerDomain`	`0`	no
`ClaimCompletion.EmailMailsPerSubject`	`int`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailLimits:MailsPerSubject` Tenant: `ClaimCompletionEmailLimits:MailsPerSubject` Core: `Veriqa:ClaimCompletion:EmailLimits:MailsPerSubject`	`10`	no
`ClaimCompletion.EmailMailsPerTransaction`	`int`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailLimits:MailsPerTransaction` Tenant: `ClaimCompletionEmailLimits:MailsPerTransaction` Core: `Veriqa:ClaimCompletion:EmailLimits:MailsPerTransaction`	`3`	no
`ClaimCompletion.EmailMethods`	`IReadOnlyList`1`	Application · Tenant · Core	—	Application: `ClaimCompletionEmailMethods` Tenant: `ClaimCompletionEmailMethods` Core: `Veriqa:ClaimCompletion:EmailMethods`	`[Push, Code, MagicLink]`	no
`ClaimCompletion.FormEnabled`	`bool`	Application · Core	—	Application: `ClaimCompletionFormEnabled` Core: `Veriqa:ClaimCompletion:FormEnabled`	`true`	no
`ClaimCompletion.FormSurface`	`ClaimFormSurface`	Application · Core	—	Application: `ClaimCompletionFormSurface` Core: `Veriqa:ClaimCompletion:FormSurface`	`Auto`	no
`ClaimCompletion.PhoneOptionalWindow`	`TimeSpan`	Application · Core	—	Application: `ClaimCompletionPhoneOptionalWindow` Core: `Veriqa:ClaimCompletion:PhoneOptionalWindow`	`00:01:00`	no
`Client.InitiateLoginUri`	`string`	Application	—	Application: `InitiateLoginUri`	not declared	no
`CompletionBehavior.Action`	`CompletionBehaviorAction`	Application · Tenant · Core	`channel`	Application: `CompletionBehavior:Action` Tenant: `CompletionBehavior:Action` Core: `Veriqa:CompletionBehavior:Action`	not declared	no
`CompletionBehavior.MenuItems`	`IReadOnlyList`1`	Application · Tenant · Core	`channel`	Application: `CompletionBehavior:MenuItems` Tenant: `CompletionBehavior:MenuItems` Core: `Veriqa:CompletionBehavior:MenuItems`	not declared	no
`CompletionBehavior.RedirectButtonText`	`string`	Application · Tenant · Core	—	Application: `CompletionBehavior:RedirectButtonText` Tenant: `CompletionBehavior:RedirectButtonText` Core: `Veriqa:CompletionBehavior:RedirectButtonText`	`Open`	no
`CompletionBehavior.RedirectUrl`	`string`	Application · Tenant · Core	`channel`	Application: `CompletionBehavior:RedirectUrl` Tenant: `CompletionBehavior:RedirectUrl` Core: `Veriqa:CompletionBehavior:RedirectUrl`	not declared	no
`ConfirmationSubjectDisplay.Surfaces`	`IReadOnlyCollection`1`	Application · Tenant · Core	—	Application: `ConfirmationSubjectDisplaySurfaces` Tenant: `ConfirmationSubjectDisplaySurfaces` Core: `Veriqa:ConfirmationSubjectDisplay:Surfaces`	`[]`	no
`HealthChecks.ChannelProbeLimit`	`TimeSpan`	Core	—	Core: `Veriqa:HealthChecks:ChannelProbeLimit`	`00:01:00`	no
`HopMode.AcceptClientSignals`	`bool`	Tenant · Core	—	Tenant: `HopMode:AcceptClientSignals` Core: `Veriqa:HopMode:AcceptClientSignals`	`true`	no
`HopMode.CollectFingerprint`	`bool`	Tenant · Core	—	Tenant: `HopMode:CollectFingerprint` Core: `Veriqa:HopMode:CollectFingerprint`	`false`	no
`HopMode.CollectGeoLocation`	`bool`	Tenant · Core	—	Tenant: `HopMode:CollectGeoLocation` Core: `Veriqa:HopMode:CollectGeoLocation`	`false`	no
`HopMode.CollectIpAddress`	`bool`	Tenant · Core	—	Tenant: `HopMode:CollectIpAddress` Core: `Veriqa:HopMode:CollectIpAddress`	`true`	no
`HopMode.CollectScannerContext`	`bool`	Tenant · Core	—	Tenant: `HopMode:CollectScannerContext` Core: `Veriqa:HopMode:CollectScannerContext`	`true`	no
`HopMode.CollectUserAgent`	`bool`	Tenant · Core	—	Tenant: `HopMode:CollectUserAgent` Core: `Veriqa:HopMode:CollectUserAgent`	`true`	no
`HopMode.EmitScannedStatus`	`bool`	Tenant · Core	—	Tenant: `HopMode:EmitScannedStatus` Core: `Veriqa:HopMode:EmitScannedStatus`	`true`	no
`HopMode.Enabled`	`bool`	Application · Tenant · Core	`channel`	Application: `HopMode:Enabled` Tenant: `HopMode:Enabled` Core: `Veriqa:HopMode:Enabled`	not declared	no
`HopMode.HopPath`	`string`	Core	—	Core: `Veriqa:HopMode:HopPath`	`/r`	no
`HopMode.QrMode`	`HopQrMode`	Application · Tenant · Core	—	Application: `HopMode:QrMode` Tenant: `HopMode:QrMode` Core: `Veriqa:HopMode:QrMode`	`PerChannel`	no
`HopMode.RedirectStyle`	`HopRedirectStyle`	Application · Tenant · Core	`channel`	Application: `HopMode:RedirectStyle` Tenant: `HopMode:RedirectStyle` Core: `Veriqa:HopMode:RedirectStyle`	not declared	no
`HopMode.ShowChannelButtonsOnAnyChannelTab`	`bool`	Application · Tenant · Core	—	Application: `HopMode:ShowChannelButtonsOnAnyChannelTab` Tenant: `HopMode:ShowChannelButtonsOnAnyChannelTab` Core: `Veriqa:HopMode:ShowChannelButtonsOnAnyChannelTab`	`true`	no
`HopMode.StoreRawUserAgent`	`bool`	Tenant · Core	—	Tenant: `HopMode:StoreRawUserAgent` Core: `Veriqa:HopMode:StoreRawUserAgent`	`false`	no
`HopMode.TokenLifetime`	`TimeSpan?`	Application · Tenant · Core	—	Application: no path Tenant: `HopMode:TokenLifetime` Core: `Veriqa:HopMode:TokenLifetime`	declared, value not printed	no
`HopMode.WarnOnRepeatScan`	`bool`	Tenant · Core	—	Tenant: `HopMode:WarnOnRepeatScan` Core: `Veriqa:HopMode:WarnOnRepeatScan`	`true`	no
`IdentityMatch.ComparableTypes`	`IReadOnlyList`1`	Application · Tenant · Core	—	Application: `IdentityMatchComparableTypes` Tenant: `IdentityMatchComparableTypes` Core: `Veriqa:IdentityMatch:ComparableTypes`	`[]`	no
`InitiatorContext.DisplayFields`	`IReadOnlyList`1`	Application · Core	—	Application: `InitiatorContextDisplayFields` Core: `Veriqa:InitiatorContext:DisplayFields`	`[application, browser, os, region]`	no
`InitiatorContext.Enabled`	`bool`	Application · Core	—	Application: `InitiatorContextEnabled` Core: `Veriqa:InitiatorContext:Enabled`	`true`	no
`Logging.Mode`	`LoggingMode`	Tenant · Core	—	Tenant: `Logging:Mode` (derived from the name) Core: `Veriqa:Logging:Mode`	`System`	no
`Logging.RetentionDays`	`int`	Core	—	Core: `Veriqa:Logging:RetentionDays`	`90`	no
`LoginConfirmation.Mode`	`LoginConfirmationMode`	Application · Tenant · Core	—	Application: `LoginConfirmationMode` Tenant: `LoginConfirmationMode` Core: `Veriqa:LoginConfirmation:Mode`	`ChannelDefault`	no
`MessageTemplates.Contract`	`MessageContract`	Application · Tenant · Core	`kind` · `transaction_type` · `action_type`	Application: `MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:Contract` Tenant: `MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:Contract` Core: `Veriqa:MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:Contract`	not declared	no
`MessageTemplates.Template`	`MessageTemplateVariant[]`	UiConfig · Application · Tenant · Core	`kind` · `transaction_type` · `action_type` · `surface` · `channel` · `device_type`	UiConfig: `MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:[BySurface:{surface}]:[ByChannel:{channel}]:[ByDevice:{device_type}]:Templates` Application: `MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:[BySurface:{surface}]:[ByChannel:{channel}]:[ByDevice:{device_type}]:Templates` Tenant: `MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:[BySurface:{surface}]:[ByChannel:{channel}]:[ByDevice:{device_type}]:Templates` Core: `Veriqa:MessageTemplates:{kind}:[ByType:{transaction_type}]:[ByAction:{action_type}]:[BySurface:{surface}]:[ByChannel:{channel}]:[ByDevice:{device_type}]:Templates`	not declared	no
`OidcServer.AccessTokenLifetimeSeconds`	`int`	Core	—	Core: `Veriqa:OpenIddict:Server:AccessTokenLifetimeSeconds`	`3600`	no
`OidcServer.AuthorizationCodeLifetimeSeconds`	`int`	Core	—	Core: `Veriqa:OpenIddict:Server:AuthorizationCodeLifetimeSeconds`	`300`	no
`OidcServer.EnableRefreshTokenRotation`	`bool`	Core	—	Core: `Veriqa:OpenIddict:Server:EnableRefreshTokenRotation`	`true`	no
`OidcServer.EnableRevocation`	`bool`	Core	—	Core: `Veriqa:OpenIddict:Server:EnableRevocation`	`true`	no
`OidcServer.Issuer`	`string`	Core	—	Core: `Veriqa:OpenIddict:Server:Issuer`	declared, value not printed	no
`OidcServer.RefreshTokenLifetimeSeconds`	`int`	Core	—	Core: `Veriqa:OpenIddict:Server:RefreshTokenLifetimeSeconds`	`1209600`	no
`OpenIddict.ClientCompatibilityQuirks`	`IReadOnlyList`1`	Application · Core	—	Application: `CompatibilityQuirks` Core: `Veriqa:OpenIddict:CompatibilityQuirksAllowApplicationOverride`	not declared	no
`RateLimit.AuthorizePermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:AuthorizePermitLimit`	`60`	no
`RateLimit.AuthorizeWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:AuthorizeWindowSeconds`	`60`	no
`RateLimit.CallbackPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:CallbackPermitLimit`	`60`	no
`RateLimit.CallbackWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:CallbackWindowSeconds`	`60`	no
`RateLimit.ConfirmationCreatePermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationCreatePermitLimit`	`60`	no
`RateLimit.ConfirmationCreateWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationCreateWindowSeconds`	`60`	no
`RateLimit.ConfirmationPagesPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationPagesPermitLimit`	`30`	no
`RateLimit.ConfirmationPagesWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationPagesWindowSeconds`	`60`	no
`RateLimit.ConfirmationResultPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationResultPermitLimit`	`60`	no
`RateLimit.ConfirmationResultWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:ConfirmationResultWindowSeconds`	`60`	no
`RateLimit.EmailStartPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:EmailStartPermitLimit`	`5`	no
`RateLimit.EmailStartWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:EmailStartWindowSeconds`	`60`	no
`RateLimit.HopResolvePermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:HopResolvePermitLimit`	`30`	no
`RateLimit.HopResolveWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:HopResolveWindowSeconds`	`60`	no
`RateLimit.HopSignalPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:HopSignalPermitLimit`	`60`	no
`RateLimit.HopSignalWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:HopSignalWindowSeconds`	`60`	no
`RateLimit.PollingPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:PollingPermitLimit`	`600`	no
`RateLimit.PollingWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:PollingWindowSeconds`	`60`	no
`RateLimit.SignalRPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:SignalRPermitLimit`	`30`	no
`RateLimit.SignalRWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:SignalRWindowSeconds`	`60`	no
`RateLimit.TokenPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:TokenPermitLimit`	`20`	no
`RateLimit.TokenWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:TokenWindowSeconds`	`60`	no
`RateLimit.UserAuthPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:UserAuthPermitLimit`	`5`	no
`RateLimit.UserAuthWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:UserAuthWindowSeconds`	`60`	no
`RateLimit.WebhookPermitLimit`	`int`	Core	—	Core: `Veriqa:RateLimit:WebhookPermitLimit`	`100`	no
`RateLimit.WebhookWindowSeconds`	`int`	Core	—	Core: `Veriqa:RateLimit:WebhookWindowSeconds`	`60`	no
`RestrictionPolicy.Channel`	`RestrictionPolicySet`	Application · Tenant · Core	`channel`	Application: `RestrictionPolicyByChannel:{channel}` Tenant: `RestrictionPolicyByChannel:{channel}` Core: `Veriqa:RestrictionPolicies:ByChannel:{channel}`	not declared	no
`RestrictionPolicy.Common`	`RestrictionPolicySet`	Application · Tenant · Core	—	Application: `RestrictionPolicy` Tenant: `RestrictionPolicy` Core: `Veriqa:RestrictionPolicies:Common`	not declared	no
`ScopesClaims.Catalog`	`IReadOnlyList`1`	Tenant · Core	—	Tenant: no path Core: no path	not declared	no
`ScopesClaims.ClaimLevel`	`ClaimRequirementLevel`	Application	`claim`	Application: `ClaimLevels:{claim}`	not declared	no
`ScopesClaims.RequireEmail`	`bool`	Application · Tenant · Core	—	Application: `RequireEmail` Tenant: `RequireEmail` Core: `Veriqa:ScopesClaims:RequireEmail`	`false`	no
`ScopesClaims.RequirePhone`	`bool`	Application · Tenant · Core	—	Application: `RequirePhone` Tenant: `RequirePhone` Core: `Veriqa:ScopesClaims:RequirePhone`	`false`	no
`Transaction.DefaultTimeZone`	`string`	UiConfig	—	UiConfig: `default_time_zone`	not declared	no
`Transaction.TtlSeconds`	`int`	UiConfig	—	UiConfig: `ttl_seconds`	not declared	no
`TransactionEngine.RejectBots`	`bool`	Application · Core	—	Application: `RejectBots` Core: `Veriqa:TransactionEngine:RejectBots`	not declared	no
`UiConfig.SelectorAssigned`	`bool`	UiConfig	—	UiConfig: `schema_version`	not declared	no

Get started

Samples

Guides

Use cases

Ready-made recipes

Cloud

Reference

Releases

Configuration reference

Veriqa:OpenIddict

Database

Server

Clients

Veriqa:TransactionEngine

Store

Veriqa:ScopesClaims

Veriqa:AuthPageDesign

Veriqa:AuthPageDesign:QrCode

Veriqa:Localization and Veriqa:ChannelDisplay

Veriqa:RateLimit

Veriqa:InitiatorContext

Veriqa:HopMode

Hop mode for one application

Infrastructure

Veriqa:Channels

InboundVerification — a required key of every channel section

OutcomeNotice — where the receipt of an outcome appears

Veriqa:CompletionBehavior

Menu and Redirect: a message with buttons

Veriqa:MessageTemplates

Health endpoints

Keys in the declaration catalog

Next steps

Channel setup

Preparing for production

​Veriqa:OpenIddict

​Database

​Server

​Clients

​Veriqa:TransactionEngine

​Store

​Veriqa:ScopesClaims

​Veriqa:AuthPageDesign

​Veriqa:AuthPageDesign:QrCode

​Veriqa:Localization and Veriqa:ChannelDisplay

​Veriqa:RateLimit

​Veriqa:InitiatorContext

​Veriqa:HopMode

​Hop mode for one application

​Infrastructure

​Veriqa:Channels

​InboundVerification — a required key of every channel section

​OutcomeNotice — where the receipt of an outcome appears

​Veriqa:CompletionBehavior

​Menu and Redirect: a message with buttons

​Veriqa:MessageTemplates

​Health endpoints

​Keys in the declaration catalog

​Next steps

Channel setup

Preparing for production

Veriqa:OpenIddict

Database

Server

Clients

Veriqa:TransactionEngine

Store

Veriqa:ScopesClaims

Veriqa:AuthPageDesign

Veriqa:AuthPageDesign:QrCode

Veriqa:Localization and Veriqa:ChannelDisplay

Veriqa:RateLimit

Veriqa:InitiatorContext

Veriqa:HopMode

Hop mode for one application

Infrastructure

Veriqa:Channels

InboundVerification — a required key of every channel section

OutcomeNotice — where the receipt of an outcome appears

Veriqa:CompletionBehavior

Menu and Redirect: a message with buttons

Veriqa:MessageTemplates

Health endpoints

Keys in the declaration catalog

Next steps