Skip to main content
You run a bot of your own — orders, support, notifications — and want sign-in and confirmation through Veriqa in the same messenger. There are several ways to combine the two. Three of them work today; three more are planned. This page compares them and points to the page that documents each.
Do not put the token of a bot that is already running into the settings of a built-in adapter. A built-in adapter that registers the webhook itself — Telegram and Viber among them — registers its own webhook for that token when the application starts and removes it when the application stops. Your bot stops receiving its events, and after a shutdown the token is left with no webhook at all.When it applies: Telegram — in UpdateMode: Webhook, which is the default; Viber — always. In Polling mode the Telegram adapter registers no webhook, but another limit applies — one poller per bot, see the Telegram section of the channel setup.To share one bot between your code and Veriqa, use one of the two shared-bot options below — in both of them the incoming events are received by your side, not by a built-in adapter.

​
Which one to choose

The choice in one pass:
  • You can publish a second bot, and a separate sign-in bot is fine for your users — two bots. Nothing changes in the bot you already run, apart from handling one start parameter.
  • Users must stay in one bot, and you are free to run one more service — the external HTTP adapter, in any language.
  • Users must stay in one bot, and your host is .NET — your own adapter in process.

​
Who owns the token and the incoming events

​
Two bots

When to choose. A separate bot for sign-in is acceptable, and you want the least change in the bot you already have. What you do. Put the handle placeholder into the address of the button the sign-in bot shows after the sign-in; your bot receives the handle as its start parameter; your server exchanges it for the identity of the user and stores the link “the user of my bot ↔ sub” on your side. Veriqa keeps no link. Known limitations:
  • The sign-in completes without the button being pressed. If the move into your bot is mandatory, your application is what enforces it.
  • The handle is single-use and short-lived.
  • With several replicas the handle needs a shared store.
  • Your bot can message first only a user who has already opened it.
  • The button can be forwarded, and whoever presses it brings the handle to your bot: check who pressed the button. Where there is nothing to compare with, the link goes to whoever presses it first.
Details, the request and the answer, and the recipe for a mandatory move — Two bots: handing the user over to your bot.

​
A shared bot through an external HTTP adapter

When to choose. One bot for both sign-in and your own scenarios, and either you are not tied to .NET, or you run the standard Veriqa image and do not want to rebuild it. What you do. Run an external adapter — a service of yours — next to Veriqa and register it as an HTTP channel by configuration. The adapter receives the platform’s events, posts the Veriqa ones to Veriqa and forwards the rest to your bot. The reference adapter for Telegram in Python, samples/python/custom-channel-telegram/, does exactly that: TELEGRAM_BOT_FORWARD_URL names the address your bot listens on, and the routing table in its README says which update goes where. Known limitations:
  • It is a separate service to run and to protect.
  • The channel has a type of its own, different from the built-in one: telegram-http in the reference adapter, not telegram.
  • In the reference adapter an update that could not be forwarded is only written to the log — there is no queue and no retry.
  • In the reference adapter a bot with a forward address passes the shared contact on to your bot as well, so the phone number on request is declared only for a bot without one.
Details — An HTTP channel adapter in any language and its reference adapters.

​
A shared bot in process, with your own .NET adapter

When to choose. One bot, your host is .NET, and you do not want another service or another hop. What you do. Write a channel adapter of your own and keep the transport of the bot in your code: it receives every event and asks the adapter’s OwnsInboundEvent whether the event belongs to Veriqa. The Veriqa events go to Veriqa, everything else to your bot. Known limitations:
  • .NET only.
  • OwnsInboundEvent is a cheap substring check and answers one-sidedly: override it with a precise check of your wire format if a false positive costs you something.
  • If the adapter declares the phone number on request, OwnsInboundEvent has to be overridden, keeping the marker check CallbackDataPrefixes.ContainsAnyMarker: the default body recognises the button markers, but a shared contact carries none.
  • A button of the phone number step that sends plain text carries no marker at all, so its press reaches your bot, not Veriqa: an optional number is then skipped when its window runs out, and a required one waits until the transaction expires. A button with a payload — marked with CallbackDataPrefixes.PhoneSkip or CallbackDataPrefixes.PhoneCancel — is recognised by the marker check. See phone number on request; the built-in Telegram adapter has the same limitation — phone number in Telegram.
Details — Build your own channel adapter and phone number on request.

​
Planned

None of the three is available yet; each removes one of the limitations above.
  • A built-in adapter that leaves the bot’s transport alone. You will be able to put the token of a bot that is already running into the settings of a built-in adapter without the adapter taking over its webhook.
  • A gateway for the built-in adapter. Veriqa will receive the incoming events of the shared bot, handle its own and deliver the rest to your bot — with the built-in channel and no adapter to write. A bot that works on polling will only change the API address it calls.
  • Confirmation by your own bot. Your bot will show the confirmation question itself and report the user’s decision to Veriqa in one call. It is meant for bots built on no-code platforms, where nothing can be placed in front of the bot.

Supported channels

Which channels ship with Veriqa and what each of them returns.