Channel setup

adapters.AddTelegram();
adapters.AddWhatsApp();
adapters.AddMax();
adapters.AddInstagram();
adapters.AddMessenger();
adapters.AddWeChat();
adapters.AddViber();
adapters.AddEmail();

​

Inbound verification level

​

Settings every chat channel shares

{
  "Veriqa": {
    "Channels": {
      "Messenger": {
        "BotName": "Acme Support",
        "SpareStartCodeEnabled": true
      }
    }
  }
}

​

Telegram

{
  "Veriqa": {
    "Channels": {
      "Telegram": {
        "Enabled": true,
        "InboundVerification": "shared_secret",
        "BotToken": "YOUR_BOT_TOKEN",
        "BotUsername": "your_login_bot",
        "UpdateMode": "Webhook",
        "WebhookBaseUrl": "https://auth.your-domain.com",
        "WebhookSecretToken": "YOUR_RANDOM_SECRET"
      }
    }
  }
}

​

WhatsApp

{
  "Veriqa": {
    "Channels": {
      "WhatsApp": {
        "Enabled": true,
        "InboundVerification": "signature",
        "Provider": "MetaCloudApi",
        "BusinessPhoneNumber": "+15551234567",
        "MetaCloudApi": {
          "PhoneNumberId": "YOUR_PHONE_NUMBER_ID",
          "AccessToken": "YOUR_ACCESS_TOKEN",
          "AppSecret": "YOUR_APP_SECRET",
          "WebhookVerifyToken": "YOUR_VERIFY_TOKEN",
          "GraphApiVersion": "v26.0"
        }
      }
    }
  }
}

​

Delivery through Twilio

{
  "Veriqa": {
    "Channels": {
      "WhatsApp": {
        "Enabled": true,
        "InboundVerification": "signature",
        "Provider": "Twilio",
        "BusinessPhoneNumber": "+15551234567",
        "Twilio": {
          "AccountSid": "YOUR_ACCOUNT_SID",
          "AuthToken": "YOUR_AUTH_TOKEN",
          "QuickReplyContentSid": "YOUR_CONTENT_SID",
          "WebhookUrl": "https://auth.your-domain.com/api/channels/whatsapp/webhook"
        }
      }
    }
  }
}

{
  "twilio/quick-reply": {
    "body": "{{1}}",
    "actions": [
      { "title": "{{2}}", "id": "{{3}}" },
      { "title": "{{4}}", "id": "{{5}}" }
    ]
  }
}

​

The prefilled message text

Sign in to Acme
Send this message to sign in.

Access code
auth_7Ks9mR3xYpL2nWq4tBvC8dEfG1hJkM5nP0qRsTuVwXy

{
  "Sign in to {app}\nSend this message to sign in.\n\nAccess code\n{code}":
    "Sign in to {app}\nSend this message to sign in.\n\nAccess code\n{code}",
  "Send this message to sign in.\n\nAccess code\n{code}":
    "Send this message to sign in.\n\nAccess code\n{code}"
}

• keep the code on its own last line — it is 48 characters long (auth_ plus a 43-character transaction id) and fits inside no frame;
• do not use *, _, ~ as graphics — WhatsApp reads them as markup (bold, italic, strikethrough). -, ., :, +, | are safe;
• frames with vertical bars (|…|) only line up inside a monospace block (triple backticks) — in an ordinary message the font is proportional and the frame falls apart. Some clients also show the raw backticks in the input box and only render monospace in the sent message, so verify such a layout on a device before rolling it out;
• horizontal rules (------) work in every client and need no wrapper.

Sign in to {app}
Send this message to sign in.

Access code
{code}

------------------------
   SIGN IN TO {app}
------------------------
Just send this message.

Access code:
{code}

------------------------
SIGN IN TO {app}
------------------------
Send this message
to confirm the sign-in.

Access code
{code}

```
+----------------------+
|  SIGN IN TO {app}    |
+----------------------+
| Just send this       |
| message to confirm.  |
+----------------------+
```
Access code
{code}

```
╔══════════════════════╗
║  SIGN IN TO {app}    ║
╠══════════════════════╣
║ Just send this       ║
║ message.             ║
╚══════════════════════╝
```
Access code
{code}

{
  "Sign in to {app}\nSend this message to sign in.\n\nAccess code\n{code}":
    "------------------------\n   SIGN IN TO {app}\n------------------------\nJust send this message.\n\nAccess code:\n{code}",
  "Send this message to sign in.\n\nAccess code\n{code}":
    "------------------------\nJust send this message to sign in.\n------------------------\n\nAccess code:\n{code}"
}

​

MAX

{
  "Veriqa": {
    "Channels": {
      "Max": {
        "Enabled": true,
        "InboundVerification": "shared_secret",
        "BotToken": "YOUR_BOT_TOKEN",
        "BotPublicName": "Your Login Bot",
        "UpdateMode": "Webhook",
        "WebhookBaseUrl": "https://auth.your-domain.com",
        "WebhookSecretToken": "YOUR_RANDOM_SECRET"
      }
    }
  }
}

​

Instagram

{
  "Veriqa": {
    "Channels": {
      "Instagram": {
        "Enabled": true,
        "InboundVerification": "signature",
        "AppSecret": "YOUR_APP_SECRET",
        "WebhookVerifyToken": "YOUR_VERIFY_TOKEN",
        "AccessToken": "YOUR_ACCESS_TOKEN",
        "AccountId": "YOUR_INSTAGRAM_ACCOUNT_ID",
        "Username": "your_login_account",
        "GraphApiBaseUrl": "https://graph.instagram.com",
        "GraphApiVersion": "v26.0"
      }
    }
  }
}

• A computer or a tablet shows the code 8 seconds after the page loads — unless the Instagram QR code on the page is a hop mode QR code. Then the code waits until the phone opens Instagram, and the sign-in page shows it under the instruction to continue on the phone 6 seconds later.
• On a phone, the code does not open by itself. Once the user has tapped the Instagram button and come back to the page, a Problem signing in link appears under the status line, for the channel tapped last; the link opens the code. A reload forgets the tap.
• The page a phone opens from a hop mode QR code that covers several channels leaves the choice of channel to that page. Tapping the Instagram button switches the page to that channel: the title and the instruction change to “Continue in Instagram” with the channel icon, the channel buttons disappear, and a Back to channel selection link below brings the choice back without affecting the sign-in. When the user comes back from the app, the Problem signing in link appears under the status line, and the code behind it comes with Copy and open Instagram, as on the launch page. Once your account answers or the sign-in ends, the way back to the choice is gone for good.
• The launch page on the phone under hop mode offers the code behind the same link 6 seconds after it took the user into the app. There the code comes with one button, Copy and open Instagram: it copies the code and opens the app. Once the code is opened, the Instagram button above it disappears from the page.

• The 24-hour window. The account may write to a user only within 24 hours of that user’s last message to it (Meta: send messages). A sign-in fits inside it: every message of the flow answers a user who has just opened the link.
• The referral may not arrive while the Meta app is in development mode. The user opens the ig.me link, and Instagram delivers nothing to the webhook. This is a limit of the platform, not of the adapter. The sign-in then starts with the code shown on the sign-in page: the user sends it to the account as a message.
• The first tap of a new user may arrive without the ref value. When the user has never written to your account, opening the ig.me link delivers nothing by itself: Instagram reports the link together with the user’s first action there — a tapped Icebreaker or a sent message (Meta: ig.me links). Set up Icebreakers for the account before you offer the channel, so that a new user has a button to tap — but that first tap may still reach Veriqa without the ref value. The user then gets the hint (unless you switched it off) and goes on with the code shown on the sign-in page, or scans the QR code again: the conversation exists by then, and Instagram reports the link at once. The link works in the Instagram mobile app only.
• The sign-in link does nothing from the open conversation with the account. When the user already has the conversation with your account open in the Instagram app, the ig.me link just returns them to it and the ref value never reaches Veriqa — the sign-in does not start. From any other screen of the app the link works. The user only has to send the code shown on the sign-in page into that conversation, or leave the conversation and open the link again. Hop mode and its redirect style make no difference. Observed on Instagram for iPhone in October 2026; the behavior belongs to the platform and may change.
• One event per delivery. When Meta packs several events into one webhook delivery, Veriqa processes one of them and ignores the rest: an event that names a sign-in (an opened link, a tapped button) comes before a shared phone number, and that before any other message.
• The text of the question is truncated to 640 characters — the limit of a message with buttons (Meta: button template).
• No user language. Instagram does not tell the adapter the user’s language, so the messages follow the language of the sign-in.
• The phone number is asked for with a button that Instagram shows only in its mobile app and only to a user whose profile has a phone number — see phone number.

​

Messenger

{
  "Veriqa": {
    "Channels": {
      "Messenger": {
        "Enabled": true,
        "InboundVerification": "signature",
        "PageId": "YOUR_PAGE_ID",
        "PageName": "your.page.username",
        "PageAccessToken": "YOUR_PAGE_ACCESS_TOKEN",
        "AppSecret": "YOUR_APP_SECRET",
        "WebhookVerifyToken": "YOUR_VERIFY_TOKEN",
        "GraphApiBaseUrl": "https://graph.facebook.com",
        "GraphApiVersion": "v26.0"
      }
    }
  }
}

• The referral may not arrive while the Meta app is in development mode. The user opens the m.me link, and Messenger delivers nothing to the webhook. This is a limit of the platform, not of the adapter. The sign-in then starts with the code shown on the sign-in page: the user sends it to the Page as a message.
• The 24-hour window. The Page answers a user within the standard messaging window of 24 hours after that user’s last message. A sign-in fits inside it: every message of the flow answers a user who has just opened the link.
• The profile needs permissions of its own. The name and the picture are read with the Business Asset User Profile Access feature, the language with the pages_user_locale permission. Without them the sign-in still completes: the user is identified by the page-scoped ID, and the token carries no given_name, family_name, picture or locale.
• One event per delivery. When Meta packs several events into one webhook delivery, Veriqa processes one of them and ignores the rest: an event that names a sign-in (an opened link, a tapped button) comes before a shared phone number, and that before any other message.
• The text of the question is truncated to 640 characters — the limit of a message with buttons.
• The language of the messages is the language of the user’s Facebook profile when the app has the pages_user_locale permission, and the language of the sign-in otherwise: the webhook itself carries no language of the user.
• The phone number is asked for with a button that Messenger shows only to a user whose profile has a phone number — see phone number.

​

WeChat

{
  "Veriqa": {
    "Channels": {
      "WeChat": {
        "Enabled": true,
        "InboundVerification": "shared_secret",
        "AppId": "YOUR_APP_ID",
        "AppSecret": "YOUR_APP_SECRET",
        "Token": "YOUR_SERVER_TOKEN",
        "ApiBaseUrl": "https://api.weixin.qq.com"
      }
    }
  }
}

• The messaging window. The account may send three messages within a minute after a scan and five within 48 hours after a message from the user. A sign-in fits inside it: the question follows the scan, the outcome follows the tapped option. A message outside the window is refused by the platform and is not sent again.
• Plaintext mode only. A delivery in the encrypted mode is not read.
• A slow answer repeats the question. The platform delivers an event again when it gets no answer within five seconds, and the channel does not tell that delivery from a new scan — the user may get the question twice. Either copy answers the sign-in.
• The OpenID and nothing else. The platform gives an Official Account neither a name, nor a picture, nor the user’s language: the token carries the base claims only, name holds the OpenID, and the messages are in the language of the sign-in.
• No phone number. An Official Account has no way to ask for a phone number in the chat, so the channel does not provide one — see phone number.
• Scanning is the confirmed way in. The channel button opens the content of the same QR code. Whether a mobile browser hands that address over to the WeChat app, and what a system camera does with the code, has not been confirmed — rely on WeChat’s own scanner.
• Several hosts, one account. The access token is obtained with the platform’s stable-token call, so hosts serving one account do not revoke each other’s tokens.
• The name wechat is taken. An HTTP channel registered under that name prevents the host from starting — rename it.

​

Viber

{
  "Veriqa": {
    "Channels": {
      "Viber": {
        "Enabled": true,
        "InboundVerification": "signature",
        "AuthToken": "YOUR_BOT_AUTH_TOKEN",
        "BotUri": "yourbot",
        "SenderName": "Your Product",
        "WebhookBaseUrl": "https://auth.your-domain.com",
        "ApiBaseUrl": "https://chatapi.viber.com"
      }
    }
  }
}

• One message before the user answers. After the conversation is opened the bot may send one message; the next one goes through only after the user has written to the bot. A sign-in fits: the question is that one message, and a tap on Confirm or Decline is the user’s answer.
• The tap shows in the chat. A button of a Viber keyboard sends its value as a message from the user, so the conversation shows a line starting with vq_confirm_ or vq_decline_.
• A sent message cannot be changed. The outcome always arrives as a new message; it also removes the question’s buttons.
• The profile is what the event carries: the name, the picture and the language of the user. The messages are in that language; without it, in the language of the sign-in.
• The phone number is asked for with the share-phone button, and Viber does not prove that the number belongs to the user — see phone number.
• No polling. The Bot API delivers events to a webhook only, so the channel cannot run on a host that is not reachable from the internet.
• The name viber is taken. An HTTP channel registered under that name prevents the host from starting — rename it.

​

Email

• Pull (magic link) — Veriqa emails a link, the user clicks it. On by default (PullEnabled).
• Push — the one-tap email — the user sends a pre-filled email to the inbound address (one tap from a button or a QR code) and Veriqa reads it. Off by default (PushEnabled); it needs inbound delivery and a sender verification policy. Push is the value in configuration; “one-tap email” is what the mode is called for users.

{
  "Veriqa": {
    "Channels": {
      "Email": {
        "Enabled": true,
        "InboundVerification": "shared_secret",
        "PublicBaseUrl": "https://auth.your-domain.com",
        "PreferredMode": "Pull",
        "PullEnabled": true,
        "PushEnabled": false,
        "TokenTtl": "00:05:00",
        "MailResendInterval": "00:00:30",
        "Outbound": {
          "Provider": "Smtp",
          "FromAddress": "login@your-domain.com",
          "FromName": "Veriqa",
          "Smtp": {
            "Host": "smtp.your-provider.com",
            "Port": 587,
            "UseSsl": false,
            "Username": "…",
            "Password": "…"
          }
        }
      }
    }
  }
}

​

Which mode to choose

• Nothing has to reach the user for the sign-in to work. The email travels the other way, so the sign-in no longer depends on your outbound mail arriving: no spam folder, no greylisting, no domain reputation. With PullEnabled: false the channel needs no SMTP at all — the options validator asks for outbound settings only when Pull is on.
• There is no link for a mail gateway to burn. Corporate mail protection opens links in incoming messages to check them, and a one-time magic link can be used up before the person clicks it. An email the user sends carries no such link.
• It proves control of the mailbox, not just that the message arrived. Following a link shows that the message reached someone — a forwarding rule or a shared mailbox included. Sending the email shows that the sender controls the box, and the sender is checked against VerificationPolicy (DmarcAlignedPass by default).
• It is the same move the messaging channels use. The user sends a ready-made message in one tap — the secret message. Email is that pattern with an email instead of a chat message, so the sign-in page teaches one habit, not two.

​

Push mode — the one-tap email

{
  "Inbound": {
    "Provider": "Webhook",
    "InboundAddress": "login@your-domain.com",
    "UsePlusAddressing": true,
    "VerificationPolicy": "DmarcAlignedPass",
    "WebhookSecretToken": "YOUR_SECRET"
  }
}

{
  "messageId": "<id@mail.example.com>",
  "from": "user@example.com",
  "envelopeSender": "user@example.com",
  "to": "login+TOKEN@your-domain.com",
  "subject": "Sign in",
  "body": "…",
  "receivedAt": "2026-01-01T12:00:00Z",
  "spf": "pass",
  "dkim": "pass",
  "dmarc": "pass"
}

​

What the user sees after the tap

• When its button is clicked or tapped, the sign-in page shows the line “The confirmation email is open in your mail app. Send it to continue.” by itself. When the user comes back to the page from the mail app while that line is still on it, the line becomes “If you have already sent the email, wait for the confirmation. It usually takes a few seconds.” A reload forgets the tap.
• An email opened from the QR code reports nothing to the sign-in page until the email arrives; from then on the page shows that the email was received and how the sign-in ended.
• A sender that passed verification is not yet a sign-in: when the sign-in has already been taken up by the account of another channel, the email does not sign in, and instead of “Sender verified” the page says “Sign-in has already started in another channel.” (“Confirmation has already started in another channel.” on a confirmation page).
• Where the sign-in window asks — the default for Email, see “The emailed-link page” below — the email does not sign the user in by itself: it proves the mailbox, and the sign-in page moves on to the question “Do you confirm the sign-in?”. Yes signs the user in; No declines the sign-in, and the application gets access_denied. With LoginConfirmation.Mode set to None the email completes the sign-in itself.

​

Email under hop mode

​

The emailed-link page

• The sign-in window asks — the default for Email. The page asks nothing. Titled “Sign-in request”, it names the application — “A sign-in to {app} was requested. If it was not you, close this page.” — and offers Continue signing in and Cancel. “Continue signing in” passes the sign-in on to the sign-in window: it uses up the link and ties the mailbox to the sign-in without completing it, and the page turns into “Return to the sign-in window and confirm the sign-in there.” with a Close button. The one question of the sign-in — confirm or decline — is asked once, on the sign-in window where the sign-in started: Yes signs the user in, and profile details the application still lacks are collected right there; No declines the sign-in, and the application gets access_denied. The same link opened again says it is invalid or has expired.
• The sign-in window does not ask (None). The link completes the sign-in when it is opened, and the page shows how the sign-in ended.

​

Sending an email again

{
  "Veriqa": {
    "Channels": {
      "Email": {
        "MailResendInterval": "00:00:30"
      }
    }
  }
}

• The interval is counted per sign-in, not per address: correcting the address and pressing the button within the interval is refused the same way.
• The sign-in email and the emails of the claims completion are counted separately, so a sign-in by an emailed link does not delay the first completion email.
• 00:00:00 switches the interval off; a negative value prevents startup. The setting is node-wide.
• The interval is not the request limit and not the email limits of the claims completion (ClaimCompletionEmailLimits): all three apply independently.
• An email that failed to go out still starts the interval — the next attempt waits it out.

​

One-tap email over IMAP

{
  "InboundVerification": "outbound_fetch",
  "PushEnabled": true,
  "Inbound": {
    "Provider": "ImapPolling",
    "InboundAddress": "login@your-domain.com",
    "UsePlusAddressing": true,
    "VerificationPolicy": "DmarcAlignedPass",
    "Imap": {
      "Host": "imap.your-provider.com",
      "Port": 993,
      "Username": "login@your-domain.com",
      "AuthMode": "Password",
      "Password": "…",
      "Folder": "INBOX",
      "PollIntervalSeconds": 10,
      "AuthservId": "mx.your-provider.com"
    }
  }
}

• An email reaches the sign-in — completes it, or ties the mailbox to it where the sign-in window asks — no later than PollIntervalSeconds plus the time of one visit to the mailbox after it has arrived.
• Only unread emails that arrived no earlier than TokenTtl ago are taken: an older email is neither read nor marked. An email that was handled — accepted or rejected — is marked as read. Nothing is ever deleted.
• The connection is TLS only and the server certificate is always validated; there is no switch that turns the validation off.
• A failure of the mailbox or of the authorization server — network, wrong password, a refused token — does not stop the application or the other channels. The error is logged without secrets and the visit is retried after 1 second, then 2, 4 and so on up to 60 seconds; the first successful visit resets the pause.
• The webhook route /api/channels/email/inbound answers 404 with this provider.
• In a multi-tenant installation every tenant with this provider is read by its own loop with its own mailbox settings.

• Authentication-Results: mx.your-provider.com; spf=pass …; dkim=pass …; dmarc=pass … — the value opens with a host name followed by ;. That name is the AuthservId.
• Authentication-Results: spf=pass …; dkim=pass …; dmarc=pass … — the value opens with a verdict (a word with =), so the server states no authserv-id. There is nothing to put into AuthservId: do not copy spf=pass there.

• VerificationPolicy: ProviderVerified cannot be combined with ImapPolling — a mailbox supplies no provider-verified sender; the host does not start with this pair.
• A mismatch between ImapPolling and an InboundVerification other than outbound_fetch is a Warning at startup, as with a messaging channel in Polling mode.

​

Mailbox sign-in with OAuth

• With a refresh token — the mailbox of a particular user, who gave the consent once. Choose it when the mailbox is an ordinary account and the provider issues refresh tokens for it.
• With the application’s credentials (client_credentials) — the application reads the mailbox without any user. Choose it when the administrator of the organization can grant the application access to the mailbox; there is no refresh token to renew.

{
  "Imap": {
    "Host": "imap.your-provider.com",
    "Username": "login@your-domain.com",
    "AuthMode": "OAuth2",
    "AuthservId": "mx.your-provider.com",
    "OAuth": {
      "TokenEndpoint": "https://auth.your-provider.com/oauth2/token",
      "ClientId": "YOUR_CLIENT_ID",
      "ClientSecret": "…",
      "RefreshToken": "…"
    }
  }
}

{
  "Imap": {
    "Host": "imap.your-provider.com",
    "Username": "login@your-domain.com",
    "AuthMode": "OAuth2",
    "AuthservId": "mx.your-provider.com",
    "OAuth": {
      "TokenEndpoint": "https://auth.your-provider.com/oauth2/token",
      "ClientId": "YOUR_CLIENT_ID",
      "ClientSecret": "…",
      "Scope": "SCOPE_FROM_YOUR_PROVIDER_DOCS"
    }
  }
}

• Microsoft 365 — Authenticate an IMAP, POP or SMTP connection using OAuth: the registration of the application, the scope for each of the two grants and, for the credentials of the application, the steps an administrator performs to let it into a mailbox. The token endpoint is described in OAuth 2.0 client credentials flow and OAuth 2.0 authorization code flow.
• Google — OAuth 2.0 mechanism names the scope of IMAP access, and Using OAuth 2.0 to Access Google APIs describes the registration of the application, the token endpoint and how a refresh token is obtained. Only the refresh token grant applies here: see the limitations below.

• The consent is given outside Veriqa. Veriqa has no consent screen and no redirect address for this: the administrator obtains the refresh token following the mail provider’s instructions and puts it into the secrets.
• A renewed refresh token is not written back. An authorization server may return a new refresh token together with an access token; Veriqa uses it until the process stops and never writes it to configuration. With a provider whose refresh tokens expire, the administrator replaces the value in the secrets.
• A Google service account is not supported — sign-in with a signed JWT (RFC 7523) is not implemented.

​

Providers

​

Your own mail body

{
  "Veriqa": {
    "MessageTemplates": {
      "sign-in-mail": {
        "Templates": [
          {
            "Subject": "Sign in to {app}",
            "Html": "<!DOCTYPE html><html lang=\"{lang}\"><body><h1>Sign in to {app}</h1><p><a href=\"{link}\">{button}</a></p><p>{qr_instruction}</p><img src=\"cid:{qr_cid}\" alt=\"{qr_alt}\" width=\"220\" height=\"220\" /></body></html>",
            "Plain": "{text_intro}\n{open_link_hint}\n{link}\n\nRequest from {browser} on {os}, {region}"
          },
          {
            "Subject": "Sign in to {app}",
            "Html": "<!DOCTYPE html><html lang=\"{lang}\"><body><h1>Sign in to {app}</h1><p><a href=\"{link}\">{button}</a></p></body></html>",
            "Plain": "{text_intro}\n{open_link_hint}\n{link}"
          }
        ]
      }
    }
  }
}

• the markup inside a variant is not escaped by the product — it is written by whoever owns the configuration. What is escaped are the slot values: they come from outside, an application over the API included;
• the visible phrases stay localization keys. {button}, {qr_instruction}, {qr_alt} and their kin are localized-text slots: the message contract states which key a slot looks at, and the translation for the recipient’s language is what gets substituted. The markup is therefore one text for every language, and there is nothing to translate as copies. The shipped email has no phrase outside such slots — {heading}, {text_intro}, {request_from_label}, {button_hint}, {valid_until_label} and the rest; the two-variant example above writes its heading and the “Request from” line into the markup, and those stay in the language you wrote them in;
• what Veriqa computes is never shortened; what comes from outside is. {link}, {valid_until} and the other values the product computes itself are substituted in full. The application name, the initiator details and a translated phrase are held to 128 characters — keep one phrase per slot short, and split a long sentence into several slots;
• the form of the QR is decided by the text, not by a setting. A variant naming {qr_cid} gets the PNG attachment; a variant naming {qr_url} instead (the link to the QR endpoint, if your composer supplies it) gets the image by URL and carries no attachment; a variant naming neither is the email without a QR. An attachment nothing points at never happens;
• there is one email, and each step of the ladder has two editions. A step is either a string (a text that suits any sink) or an object { "Subject": …, "Html": …, "Plain": … }. Each edition is optional, but a step must specify at least one: a step specifying none fails startup, naming the message kind and the number of the step. A step specifying only Html does not serve the plain-text part — the selection simply moves on down the ladder, so the two parts of one email may come from different steps. The subject is then taken from the step chosen for Html;
• the last step of the ladder must rely on guaranteed slots only (app, valid_until, link, lang). The initiator details and the QR are not guaranteed: a transaction without them simply reaches the step that names none of them — no empty paragraph in the email, and no literal {browser}. This is counted per edition: the selection runs among the steps specifying the edition asked for, so a ladder has two “last” steps — the last one with Html and the last one with Plain — and the rule holds for both. A ladder whose last Html step names {browser}, with only the Plain one made slot-free, fails startup;
• an HTML-only email (or a text-only one) is a legitimate declaration. When no step specifies Plain, the email goes out without a text part: no error in the log, no substitution of one edition for the other. Which is exactly why you should make sure a one-part email is your choice and not a forgotten edition: in the data the two are indistinguishable.

builder.Services.AddSingleton<IEmailMessageComposer, CorporateEmailComposer>();

​

Address normalization

{
  "Veriqa": {
    "Channels": {
      "Email": {
        "Normalization": {
          "LowercaseDomain": true,
          "LowercaseLocalPart": true,
          "ProviderSpecificCanonicalization": false
        }
      }
    }
  }
}

​

Letting the client pick a channel

GET /connect/authorize
  ?client_id=my-app
  &response_type=code
  &scope=openid profile
  &acr_values=channel:telegram

​

Checklist

​

Next steps