• Серия voir-pages
  • стр. 15 / 26
  • живых соединений 3
  • портов в продукте реализовано 0

Интеграция — это не логотип партнёра на сайте. Это порт с обработчиком, который отвечает на запрос или честно помечен как целевая архитектура.

Страницы интеграций обычно выглядят как стена логотипов: тридцать знакомых названий и ни одного ответа на вопрос «а что именно работает». Мы сделали наоборот. Здесь каждое соединение имеет статус, и статус проверяется запросом к живому эндпоинту, а не планом работ. На день публикации картина такая: в продукте VOIR AI не реализовано ни одного подключения — продукт не запущен. Три соединения действительно работают в экосистеме Marisova, на которой мы строим: Telegram Bot API, Telegram Stars и ЮKassa. Шесть портов продукта — CRM, платёжный шлюз, почта и календарь, телефония, хранилища данных, событийная шина — спроектированы и помечены как целевая архитектура. Живые соединения не продаются и не являются частью продукта: они доказывают, что мы умеем доводить интеграцию до прода, а не что она у нас уже есть.

3 живых соединения · экосистема Marisova 6 портов продукта · целевая архитектура

Смотреть карту шины Статусы честно

Демонстрация · карта шины

Один и тот же путь, два разных мира

Интеграция проверяется не списком названий, а прохождением сигнала: запрос вошёл, дошёл до обработчика, обработчик ответил, факт записан. Мы показали один путь — «клиент платит и получает доступ» — в двух сценариях. Первый описывает реально работающий контур экосистемы Marisova: там каждый шаг подтверждён живым кодом. Второй проходит тем же маршрутом по продукту VOIR AI и упирается в закрытые порты — потому что продукта ещё нет. Переключите сценарий, чтобы увидеть разницу. Демонстрация проигрывает заранее записанные сценарии и не подключена к живым сервисам; факты изложены текстом в разделах «Живые соединения» и «Целевая архитектура».

Структурные числа страницы: 3 живых соединения, 6 портов целевой архитектуры, 2 сценария демонстрации, 0 реализованных подключений в продукте.

Шина интеграций · сигнал от клиента до доступа

Демонстрация · подготовленный сценарий
  1. USER Клиент и интерфейс ожидает
  2. CHANNEL Канал входа: бот, мини-приложение ожидает
  3. PAYMENTS Платёжный провайдер ожидает
  4. WEBHOOK Подтверждение факта ожидает
  5. ACCESS Доступ и запись в данные ожидает
Журнал и состояния портов — записанный сценарий, не живой прогон.

Живые соединения работает в экосистеме

Три интеграции, которые отвечают на запрос сегодня

Это не интеграции продукта VOIR AI — это рабочие соединения экосистемы Marisova, на которой мы строим и которой пользуемся ежедневно. Мы приводим их по одной причине: они доказывают, что архитектура на этой странице не выдумана, а опробована на себе. Каждая карточка содержит проверяемый факт: состояние сервиса, ответ эндпоинта или наличие обработчика в живом коде. Клиенту эти интеграции не передаются и не продаются.

TG-BOT

Telegram Bot API

живое соединение

Бот @marisova_rubot — точка входа экосистемы: авторизация пользователя, запуск мини-приложения, уведомления владельцу о продажах, доставка контента. Обработка обновлений, inline-клавиатуры, WebApp-ссылки и deep-link-параметры startapp работают в проде. Для VOIR AI это прототип канала входа: в целевой архитектуре клиент общается с системой через тот же привычный мессенджер, а не через отдельный портал, который нужно запоминать.

Факт: системный сервис бота active running на сервере экосистемы, код бота содержит обработчики обновлений и инвойсов.

TG-STARS

Telegram Stars (XTR)

живое соединение

Встроенная валюта Telegram: инвойсы создаются с пустым provider_token и валютой XTR, есть нативные автопродлеваемые подписки. Полный цикл проходит внутри мессенджера — без перехода на внешний сайт, без ввода карты, без отдельной платёжной формы. Обработчики pre_checkout_query и successful_payment подтверждают факт оплаты и открывают доступ. Для продукта это образец короткого платёжного контура: минимум шагов между намерением и результатом.

Факт: в живом коде бота присутствуют инвойсы XTR и оба платёжных обработчика; тарифы экосистемы priced в Stars.

YOOKASSA

ЮKassa API v3

живое соединение

Платёжный рельс для оплаты картой в рублях — там, где Stars не подходит. Реализован отдельным модулем на стандартной библиотеке: создание платежа с ключом идемпотентности, redirect-подтверждение, проверка статуса через API как источник истины, возвраты. Вебхуки провайдера не имеют подписи, поэтому подлинность проверяется двумя способами: IP-allowlist'ом ЮKassa и повторным запросом статуса платежа. Это принцип, который мы перенесём в продукт: уведомлению не верим на слово, факт перепроверяем.

Факт: публичная витрина SKU отвечает HTTP 200, маршруты создания и статуса платежа отвечают 401 — обработчики существуют и закрыты авторизацией.

Рядом с этими тремя соединениями в экосистеме работают и внутренние сервисы, которые правильнее назвать инфраструктурой, а не интеграциями: генерация PDF через headless-браузер, распознавание речи, поиск по книжному корпусу, API колл-центра с очередью звонков и расшифровками. Последний — важное честное уточнение: API существует и отвечает, но живые звонки через провайдера телефонии не подключены. Поэтому в таблице статусов телефония остаётся в зоне целевой архитектуры, а не в живых соединениях.

Целевая архитектура не реализовано

Шесть портов, которые спроектированы, но не подключены

Порт — это не «мы планируем поддержку». Порт описывает, какие данные входят, какие выходят, кто владеет соединением и что происходит при отказе. Ниже — шесть портов продукта VOIR AI в том виде, в каком они спроектированы. Ни по одному из них не написано кода, и мы не показываем кнопки подключения: элемент интерфейса, который выглядит рабочим и не работает, — это обман, даже если он красивый.

CRM: 1С, Битрикс24, amoCRM

Целевая архитектура

Порт сделок и контактов. В целевой архитектуре AI-продажи читают воронку, обогащают сделку данными из переписки и возвращают следующий шаг — а отдел не знает, какая именно CRM подключена: он работает с нормализованной моделью сделки через адаптер. Направление синхронизации двустороннее, конфликт разрешается в пользу записи, изменённой позже, с фиксацией обеих версий в журнале.

Почему не реализовано: нет продукта и нет клиентов, чьи CRM можно было бы подключать.

Платёжный шлюз продукта

Целевая архитектура

Порт оплаты тарифов VOIR AI. Отдельная сущность, а не копия экосистемного рельса: у продукта свои тарифы, свои документы, свой учёт. Требования к контуру уже сформулированы и опробованы на ЮKassa: идемпотентность создания платежа, статус из API как источник истины, перепроверка уведомлений, возвраты с журналом. Реализации нет — тарифы на странице цен являются планом запуска, а не действующим предложением.

Почему не реализовано: продукт не запущен, продавать нечего.

Почта и календарь

Целевая архитектура

Порт переписки и расписания. AI-операции получают из него входящие письма как события процесса, а AI CEO — занятость владельца для планирования. Принцип тот же: система читает и предлагает, но не отправляет письмо и не переносит встречу без явного подтверждения человека. Автономное действие наружу — только по разрешению, записанному в регламенте.

Почему не реализовано: порт спроектирован, код не написан.

Телефония

Целевая архитектура

Порт звонков: входящие как события, исходящие по подтверждённому сценарию, расшифровка и резюме разговора как артефакт. В экосистеме Marisova существует API колл-центра — очередь, кампании, расшифровки — но живые звонки через провайдера телефонии не подключены, поэтому в живые соединения мы этот пункт не записываем. Честная формулировка: интерфейс есть, канала нет.

Почему не реализовано: нет подключения к провайдеру телефонии ни в экосистеме, ни в продукте.

Хранилища данных и BI

Целевая архитектура

Порт read-only-доступа к витринам и отчётам. AI-финансы и AI-исследования читают из него показатели, не имея права писать в чужое хранилище. Ограничение принципиальное: система, которая умеет изменять исходные данные, перестаёт быть источником доверия к отчёту. Доступ — по отдельным учётным данным с минимальной достаточной областью.

Почему не реализовано: порт спроектирован, код не написан.

Событийная шина и вебхуки

Целевая архитектура

Порт, через который внешние системы сообщают продукту о фактах: оплата прошла, заявка создана, документ подписан. Шина — основа цикла AI CEO: событие становится триггером задачи, а не поводом для ручного мониторинга. Требования уже опробованы на вебхуках ЮKassa: уведомление не является доказательством, факт перепроверяется запросом к источнику. Реализации в продукте нет.

Почему не реализовано: шина продукта не написана; в экосистеме работают только вебхуки платёжного провайдера.

Принципы подключения

Четыре правила, которые не зависят от названия сервиса

Интеграции приходят и уходят: провайдеры меняют API, сервисы закрываются, требования регуляторов обновляются. Правила ниже описывают не конкретные соединения, а то, как мы подключаем что угодно. Они выведены из практики экосистемы Marisova и применяются к портам продукта в целевой архитектуре.

Уведомление — не доказательство

Вебхук может прийти подделанным, дублированным или устаревшим. Факт операции подтверждается запросом к источнику истины — статус платежа или записи читается через API провайдера, а не берётся из тела уведомления. Дополнительно соединение ограничивается по списку адресов провайдера. Именно так устроен живой контур ЮKassa в экосистеме.

Идемпотентность обязательна

Сеть рвётся, запросы повторяются, провайдер возвращает 500, не означая неуспех операции. Каждое создающее действие несёт уникальный ключ, чтобы повтор не породил второй платёж или вторую запись. «Сначала проверь статус, потом принимай решение» — обязательный порядок обработки сбоя.

Минимальная достаточная область

Подключение получает ровно те права, которые нужны порту: чтение сделок без права их удаления, доступ к витрине отчётов без права записи, отправка уведомления без доступа к переписке. Ключи хранятся вне кода и не попадают ни в журнал, ни в отчёт, ни на эту страницу.

Отказ порта не роняет систему

Внешний сервис недоступен — это штатная ситуация, а не авария. Порт обязан иметь таймаут, повтор с ограничением числа попыток и понятное состояние «данные не получены», которое отдел передаёт наверх честно. Молчаливая подмена реальных данных заглушкой запрещена: она превращает сбой в неправдоподобный отчёт.

Статусы

Два столбца статуса: продукт и наш собственный цех

Таблица разделена намеренно. Левый столбец — что реализовано в продукте VOIR AI (сейчас ни одного подключения). Правый — что уже работает у нас внутри экосистемы Marisova и каким фактом это подтверждено. Правый столбец нельзя читать как обещание клиенту: наши внутренние интеграции не продаются и не передаются — они лишь доказывают, что требования к портам не выдуманы, а опробованы на живом контуре.

Статус интеграций на 3 ноября 2026 года. Проверено запросами к живым эндпоинтам и состоянием сервисов — не по планам.
Интеграция В продукте VOIR AI В экосистеме Marisova (внутреннее)
Telegram Bot API не реализовано
Целевая архитектура: канал входа клиента и доставки отчётов		 живое соединение
Бот @marisova_rubot: авторизация, мини-приложение, уведомления, доставка контента. Системный сервис в состоянии active running
Telegram Stars (XTR) не реализовано
Целевая архитектура: короткий платёжный контур внутри мессенджера		 живое соединение
Инвойсы в XTR с автопродлением, обработчики pre_checkout_query и successful_payment в живом коде бота
ЮKassa API v3 не реализовано
Целевая архитектура: оплата тарифов продукта картой		 живое соединение
Витрина SKU отвечает 200; маршруты создания и статуса платежа отвечают 401 — обработчики есть и закрыты авторизацией
CRM: 1С, Битрикс24, amoCRM не реализовано
Целевая архитектура: нормализованная модель сделки через адаптер		 не существует
Коннекторов нет ни в экосистеме, ни в продукте
Платёжный шлюз продукта не реализовано
Целевая архитектура: собственные тарифы, документы и учёт VOIR AI		 другой продукт
Платёжный контур экосистемы обслуживает marisova.ru и не является частью VOIR AI
Почта и календарь не реализовано
Целевая архитектура: письма как события процесса, занятость для планирования		 не существует
Подключения к почтовым провайдерам и календарям нет
Телефония не реализовано
Целевая архитектура: звонки как события, расшифровка и резюме как артефакт		 частично
API колл-центра существует и отвечает (очередь, кампании, расшифровки), но живые звонки через провайдера телефонии не подключены
Хранилища данных и BI не реализовано
Целевая архитектура: read-only-доступ к витринам и отчётам		 не существует
Подключения к внешним хранилищам нет; внутренние базы экосистемы интеграцией не являются
Событийная шина и вебхуки продукта не реализовано
Целевая архитектура: событие становится триггером задачи цикла AI CEO		 частично
Работают вебхуки платёжного провайдера с IP-allowlist'ом и перепроверкой статуса; общей шины событий в экосистеме нет
Интерактивная демонстрация шины на этой странице Демонстрация
Записанные сценарии в браузерном скрипте		 не живой сервис
Не обращается во внешнюю сеть, не отправляет платежей, ничего не исполняет и не собирает
Интеграция как услуга клиенту не реализовано
Целевая архитектура: клиент подключает свои системы к VOIR AI		 не существует
Клиентов нет, продукт не запущен; внутренние интеграции экосистемы клиенту не передаются

Безопасность соединений

Интеграция расширяет поверхность атаки — и это надо признать

Каждый подключённый сервис — это дополнительная дверь в систему. Поэтому требования безопасности к портам не менее важны, чем требования к данным. Ниже — правила, которые уже применяются в живом контуре экосистемы и закладываются в целевую архитектуру продукта.

Ключи вне кода

Учётные данные интеграций хранятся в окружении сервиса и не попадают ни в исходники, ни в журнал, ни в отчёты. На этой странице нет и не будет ни одного ключа — даже замаскированного: сам факт публикации секрета уже является утечкой.

Проверяемый источник

Там, где провайдер не подписывает уведомления, подлинность подтверждается иначе: ограничением по списку адресов провайдера и повторным запросом статуса через API. Уведомление трактуется как сигнал проверить, а не как готовый факт.

Разделение доступов

Платёжные маршруты, работающие с данными пользователя, закрыты авторизацией: без подтверждения личности запрос получает отказ, а не данные. Публично остаётся только то, что предназначено всем, — например витрина позиций с ценами.

Действие наружу — по подтверждению

Система не отправляет письмо, не совершает платёж и не переносит встречу самостоятельно, если это не оговорено регламентом явно. Автономность заканчивается там, где начинается необратимое внешнее действие: для него требуется подтверждение человека.

Границы

Что эта страница НЕ утверждает

Честность — требование владельца проекта, а не маркетинговый ход. Фиксируем границы явно, чтобы их нельзя было прочитать двояко.

  • В продукте VOIR AI нет ни одной интеграции. Все шесть портов целевой архитектуры не реализованы в коде продукта. Живые соединения принадлежат экосистеме Marisova и частью продукта не являются.
  • Клиентов и внедрений нет. На странице нет логотипов партнёров, кейсов подключения, отзывов и метрик внедрения — потому что нет ни одного внедрения. Мы не рисуем стену логотипов.
  • Демонстрация записана заранее. Оба сценария движения сигнала по шине проигрываются браузерным скриптом и не обращаются к живым сервисам: ни к платёжным провайдерам, ни к Telegram, ни во внешнюю сеть вообще.
  • Неработающих кнопок нет. Мы не публикуем элементы «Подключить CRM», «Привязать почту» или форму выбора интеграций: всё, что выглядит рабочим, обязано работать. Интерактив на странице — только переключатели сценариев демонстрации, якоря и ссылки на реальные страницы.
  • Телефония не заявлена как живая. API колл-центра в экосистеме существует, но канала звонков через провайдера телефонии нет. Поэтому телефония стоит в целевой архитектуре, а не в живых соединениях.
  • Секреты не публикуются. Ни идентификаторы магазинов, ни ключи API, ни адреса внутренних сервисов на этой странице не приводятся. Статусы проверялись запросами к эндпоинтам; сами учётные данные остались в окружении сервера.

Вопросы и ответы

Частые вопросы об интеграциях

Какие интеграции VOIR AI работают прямо сейчас?

В продукте VOIR AI — ни одной: продукт не запущен, клиентов нет. Три соединения действительно работают в экосистеме Marisova, на которой мы строим: Telegram Bot API (бот @marisova_rubot как системный сервис), Telegram Stars (инвойсы в XTR с автопродлением) и ЮKassa API v3 (витрина SKU и платёжные маршруты). Это наши внутренние рабочие интеграции, они не продаются и не являются частью продукта VOIR AI. Все шесть портов продукта — CRM, платёжный шлюз, почта и календарь, телефония, хранилища данных, событийная шина — относятся к целевой архитектуре.

Как вы проверяли, что соединение живое?

Запросом к живому эндпоинту, а не по плану работ. Для ЮKassa: публичная витрина SKU отвечает HTTP 200, а маршруты создания платежа и статуса платежа отвечают 401 — то есть обработчик существует и закрыт авторизацией. Для Telegram: системный сервис бота в состоянии active running, в живом коде бота присутствуют инвойсы в валюте XTR и обработчики pre_checkout_query и successful_payment. Именно поэтому таблица статусов на этой странице разделена на два столбца: «в продукте» и «в экосистеме».

Можно подключить VOIR AI к нашей CRM сегодня?

Нет. Коннектора к 1С, Битрикс24 или amoCRM не существует ни в каком виде: есть описание порта в целевой архитектуре и понимание, какие данные должны через него ходить. Мы сознательно не публикуем кнопку «Подключить CRM», которая вела бы в никуда, — неработающая кнопка, выглядящая как реальная, для нас форма обмана.

Почему живые платежи не считаются интеграцией продукта?

Потому что они обслуживают другой продукт. Telegram Stars и ЮKassa принимают оплату за подписки и услуги сервиса marisova.ru — это экосистема Marisova. Продукт VOIR AI не запущен, у него нет ни тарифов в продаже, ни платёжного контура. Перенести работающий платёжный рельс технически реально, но на день публикации этой страницы он не является частью VOIR AI, и мы не выдаём его за готовую возможность.

Как интеграции связаны с отделами AI?

Интеграции — это периметр, через который отделы получают данные и возвращают результат. AI-продажи работают со сделками из CRM, AI-финансы — с операциями платёжного шлюза, AI-операции — с событиями шины, AI-маркетинг — с почтовыми и мессенджер-каналами. В целевой архитектуре отдел не знает, какая именно CRM подключена: он работает с нормализованными данными через порт. Подробно устройство отделов описано на соответствующих страницах, а сборка отделов в систему — на странице AI Operating System.

Демонстрация на странице подключается к живым сервисам?

Нет. Это «Демонстрация»: браузерный скрипт проигрывает два заранее записанных сценария — «живой контур» (как реально устроен путь оплаты в экосистеме Marisova) и «целевая архитектура» (тот же путь в продукте VOIR AI, где все порты закрыты). Скрипт не отправляет запросов к платёжным провайдерам, к Telegram и вообще во внешнюю сеть; он ничего не исполняет и не собирает.

Нужна интеграция, которой здесь нет?

Продукт VOIR AI в разработке, клиентов нет, и мы не собираем заявки «в лист ожидания» через эту страницу. Напишите нам напрямую: расскажите, какие системы у вас уже работают и какой путь данных нужно автоматизировать — мы честно скажем, что из этого спроектировано, что уже опробовано в нашей экосистеме, а чего не существует ни в каком виде. Архитектуру системы в целом смотрите на странице AI Operating System, состав отделов — на главной, конвейер доставки — на странице AI-разработки.

Написать нам Планы запуска и тарифы