> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# У меня уже есть бот
> В мессенджере, через который входят ваши пользователи, у вас уже работает бот. Как использовать его вместе с Veriqa: какой вариант выбрать, кто владеет токеном бота и входящими событиями, что поменять у себя — и что работает уже сейчас, а что планируется.
У вас есть собственный бот — заказы, поддержка, уведомления, — и в том же мессенджере вы хотите
вход и подтверждение через Veriqa. Совместить одно с другим можно несколькими способами: три
работают уже сейчас, ещё три планируются. Эта страница их сравнивает и ведёт на страницу, где
каждый описан подробно.
**Не вписывайте токен уже работающего бота в настройки встроенного адаптера.** Встроенный
адаптер, который сам регистрирует вебхук у платформы, — это MAX, Telegram и Viber — при старте
приложения регистрирует на этот токен свой вебхук, а при остановке снимает его. В Telegram и
Viber вебхук вашего бота окажется занят, и бот перестанет получать свои события; после остановки
приложения вебхука у токена не останется вовсе. Адаптер MAX при старте подписывает у платформы
свой адрес, а при остановке снимает эту подписку.
Когда это происходит: MAX и Telegram — в режиме `UpdateMode: Webhook`, а это значение по
умолчанию; Viber — всегда. В режиме `Polling` адаптер MAX вебхук не подписывает, но обновления
забирает сам — токеном бота. В режиме `Polling` адаптер Telegram вебхук не регистрирует, но
действует другое ограничение — **один опрашивающий на бота**, см.
[раздел Telegram в настройке каналов](/docs/ru/guides/channels#telegram).
Чтобы один бот работал и на ваш код, и на Veriqa, возьмите один из двух вариантов общего бота
ниже: в обоих входящие события принимает ваша сторона, а не встроенный адаптер.
## Какой вариант выбрать
| Вариант | Коротко | Статус |
| - | - | - |
| [Два бота](#два-бота) | У Veriqa свой бот входа; после входа он показывает кнопку в ваш бот, а в её адресе — одноразовый handle, который ваш сервер меняет на идентичность вошедшего пользователя. Привязку храните вы | Работает сейчас |
| [Общий бот через внешний HTTP-адаптер](#общий-бот-через-внешний-http-адаптер) | Входящими владеет ваш сервис: события Veriqa он отдаёт Veriqa, остальное — вашему боту | Работает сейчас |
| [Общий бот в процессе, свой адаптер на .NET](#общий-бот-в-процессе-свой-адаптер-на-net) | Ваш собственный адаптер раздаёт события через `OwnsInboundEvent` | Работает сейчас |
| [Встроенный адаптер, который не трогает транспорт бота](#планируется) | Вписанный в настройки токен работающего бота не теряет свой вебхук | Планируется |
| [Шлюз для встроенного адаптера](#планируется) | Veriqa принимает входящие, своё обрабатывает, остальное доставляет вашему боту; бот на поллинге меняет только адрес API | Планируется |
| [Подтверждение вашим ботом](#планируется) | Бот сам показывает вопрос и присылает решение одним вызовом — для ботов, собранных в конструкторах | Планируется |
Выбор в один проход:
* **Можете завести второго бота, и отдельный бот входа пользователей не смущает** — два бота. В уже
работающем боте меняется одно: он учится принимать стартовый параметр.
* **Пользователь должен оставаться в одном боте, и вы готовы держать ещё один сервис** — внешний
HTTP-адаптер, на любом языке.
* **Пользователь должен оставаться в одном боте, а ваш хост — на .NET** — свой адаптер в процессе.
## Кто владеет токеном и входящими событиями
| Вариант | Токен бота | Входящие события принимает |
| - | - | - |
| Два бота | Токенов два: у бота входа — в настройках Veriqa, у вашего бота — у вас | Каждый бот — свои |
| Общий бот через внешний HTTP-адаптер | Один, хранится в вашем сервисе-адаптере. Veriqa его не запрашивает | Ваш сервис-адаптер; события Veriqa он отправляет в Veriqa |
| Общий бот в процессе, свой адаптер на .NET | Один, хранится в вашем коде внутри хоста | Ваш код; события Veriqa он передаёт адаптеру |
## Два бота
**Когда выбирать.** Отдельный бот для входа вас устраивает, а менять уже работающего бота хочется
как можно меньше.
**Что делаете вы.** Ставите плейсхолдер handle в адрес кнопки, которую бот входа показывает после
входа; ваш бот получает handle стартовым параметром; ваш сервер меняет его на идентичность
пользователя и хранит привязку «пользователь моего бота ↔ `sub`» у себя. Veriqa привязок не хранит.
**Известные ограничения:**
* Вход завершается и без нажатия кнопки. Если переход в ваш бот обязателен, обеспечивает это ваше
приложение.
* Handle одноразовый и живёт недолго.
* При нескольких репликах для handle нужен общий стор.
* Написать первым ваш бот может только тому пользователю, который его уже открывал.
* Кнопку можно переслать, и handle вашему боту принесёт тот, кто её нажал: проверяйте, кто нажал
кнопку. Где сверять не с чем, связку получает тот, кто нажал первым.
Подробности, запрос с ответом и рецепт обязательного перехода —
[Два бота: передача пользователя вашему боту](/docs/ru/scenarios/channel-linking#два-бота-передача-пользователя-вашему-боту).
## Общий бот через внешний HTTP-адаптер
**Когда выбирать.** Один бот и для входа, и для ваших сценариев, а к .NET вы не привязаны — либо
запускаете стандартный образ Veriqa и пересобирать его не хотите.
**Что делаете вы.** Поднимаете рядом с Veriqa внешний адаптер — свой сервис — и регистрируете его
конфигурацией как HTTP-канал. Адаптер принимает события платформы, события Veriqa отправляет в
Veriqa, остальное пересылает вашему боту. Референсный адаптер Telegram на Python,
`samples/python/custom-channel-telegram/`, делает именно это: `TELEGRAM_BOT_FORWARD_URL` задаёт
адрес, на котором слушает ваш бот, а какой апдейт куда уходит — в таблице маршрутизации его README.
**Известные ограничения:**
* Это отдельный сервис: его нужно запускать и защищать.
* У канала собственный тип, отличный от встроенного: в референсном адаптере — `telegram-http`, а не
`telegram`.
* В референсном адаптере апдейт, который не удалось переслать, только пишется в лог — ни очереди,
ни повторов нет.
* В референсном адаптере бот с адресом пересылки отдаёт вашему боту и присланный контакт, поэтому
телефон по запросу объявляется только для бота без такого адреса.
Подробнее — [HTTP-адаптер канала на любом языке](/docs/ru/guides/custom-channel-adapter#http-адаптер-канала-на-любом-языке)
и его [референсные адаптеры](/docs/ru/guides/custom-channel-adapter#референсные-адаптеры).
## Общий бот в процессе, свой адаптер на .NET
**Когда выбирать.** Один бот, ваш хост — на .NET, и ни ещё одного сервиса, ни лишнего сетевого шага
вы не хотите.
**Что делаете вы.** Пишете собственный адаптер канала и оставляете транспорт бота в своём коде: он
принимает каждое событие и спрашивает у `OwnsInboundEvent` адаптера, принадлежит ли оно Veriqa.
События Veriqa уходят в Veriqa, всё остальное — вашему боту.
**Известные ограничения:**
* Только .NET.
* `OwnsInboundEvent` — дешёвая подстрочная проверка, и ответ у неё односторонний: если ложное
срабатывание вам чем-то стоит, переопределите её точной проверкой своего wire-формата.
* Если адаптер объявляет телефон по запросу, `OwnsInboundEvent` нужно переопределить, сохранив
проверку маркеров `CallbackDataPrefixes.ContainsAnyMarker`: тело по умолчанию узнаёт маркеры
кнопок, а у присланного контакта маркера нет.
* У кнопки шага телефона, которая отправляет обычный текст, маркера нет вовсе, поэтому её нажатие
уходит вашему боту, а не Veriqa: необязательный номер тогда пропускается по истечении окна, а
обязательный ждёт, пока не истечёт транзакция. Кнопку с payload — с маркером
`CallbackDataPrefixes.PhoneSkip` или `CallbackDataPrefixes.PhoneCancel` — проверка маркеров
узнаёт. См. [телефон по запросу](/docs/ru/guides/custom-channel-adapter#телефон-по-запросу); у
встроенного адаптера Telegram то же ограничение —
[номер телефона в Telegram](/docs/ru/guides/phone-number#telegram).
Подробнее — [Свой канальный адаптер](/docs/ru/guides/custom-channel-adapter) и
[телефон по запросу](/docs/ru/guides/custom-channel-adapter#телефон-по-запросу).
## Планируется
Ни один из трёх вариантов пока не доступен; каждый снимает одно из ограничений выше.
* **Встроенный адаптер, который не трогает транспорт бота.** Токен уже работающего бота можно будет
вписать в настройки встроенного адаптера, и адаптер не займёт его вебхук.
* **Шлюз для встроенного адаптера.** Veriqa будет принимать входящие события общего бота, своё
обрабатывать, а остальное доставлять вашему боту — со встроенным каналом и без собственного
адаптера. Боту на поллинге достаточно будет сменить адрес API, к которому он обращается.
* **Подтверждение вашим ботом.** Ваш бот сам покажет вопрос подтверждения и сообщит решение
пользователя в Veriqa одним вызовом. Вариант рассчитан на ботов, собранных в конструкторах: там
между платформой и ботом ничего поставить нельзя.
Какие каналы входят в поставку — MAX, Telegram, WhatsApp, другие мессенджеры и Email — и что
возвращает каждый.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.