Платформа Vitiana API Plus — общий обзор и концепция

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение этого документа

Этот документ написан простым языком без технических особенностей и терминов.

Документ объясняет: что такое платформа Vitiana API Plus, дальше "платформа Vitiana", какие задачи бизнеса она решает, кто и как на ней зарабатывает, чем она отличается от существующих систем, в каких странах работает, какие сроки и инвестиции реально требуются, и чего она сознательно не делает.

Технические подробности этого документа сведены к минимуму. Желающие глубже разобраться в архитектуре могут обратиться к главной архитектурной оси или другим документам платформы.

Что такое платформа Vitiana — короткий ответ

Платформа Vitiana — это технологическая платформа для туристической индустрии, которая объединяет данные от множества поставщиков туристических услуг и продаёт доступ к этим объединённым данным разным каналам продаж.

Если совсем просто — платформа Vitiana работает как современный «оптовый рынок туристических услуг», на котором:

• с одной стороны стоят поставщики — отели, авиакомпании, экскурсионные бюро, перевозчики, сервисы аренды транспорта (их сотни);
• с другой стороны стоят покупатели платформы — туристические агентства, наши собственные сайты, партнёрские интернет-витрины, корпоративные службы путешествий;
• посредине — платформа Vitiana, которая делает всё, что нужно для того, чтобы покупатели получили чистые, проверенные, удобные данные и могли совершать продажи через единый интерфейс.

При этом платформа Vitiana — не «ещё один сайт по продаже отелей». Сайт у Vitiana есть (например, vitrip.store), он работает как один из каналов продаж, но сама платформа значительно больше сайта.

Какую проблему решает платформа

Туристическая индустрия в восточной Европе и в Казахстане сталкивается с одной общей проблемой: получить, обработать и продать качественные туристические данные сложно и дорого.

Каждое туристическое агентство, каждая онлайн-витрина, каждый корпоративный сервис путешествий, который хочет продавать туры или отели:

• должен подключиться к множеству поставщиков (это технически сложно, требует команды разработчиков);
• получает от каждого поставщика данные в своём формате (разные структуры, разные правила, разные ошибки);
• должен сам нормализовать всё это (привести к общему виду, проверить, очистить);
• должен сам обрабатывать сложные сценарии (отмены, изменения, частичные подтверждения, задержки от поставщиков, различные правила возврата);
• должен сам разрабатывать интерфейсы для своих клиентов;
• должен сам обеспечивать соответствие требованиям регуляторов разных стран.

Это огромный объём работы. Большинство малых и средних игроков на рынке либо не справляются (продолжают работать вручную), либо упрощают работу (снижают качество), либо отказываются от собственного канала (становятся посредниками крупных игроков на их условиях).

Платформа Vitiana берёт всю эту техническую и операционную сложность на себя, и предоставляет покупателям готовый платформенный слой:

• единый формат данных от всех поставщиков;
• проверка качества данных и обнаружение проблем;
• готовые инструменты для бронирования, отмен, изменений;
• единый рабочий кабинет для агентств;
• единый программный интерфейс (API) для технических партнёров;
• готовые витрины (в случае нашего собственного канала vitrip.store);
• модуль сборки сложных туров (Tour Builder).

Покупатель платформы платит за доступ к этому платформенному слою — за труд платформы, не за «количество найденных отелей».

Главная новизна — Tour Builder

Большинство туристических платформ на рынке — это «каталоги отелей с возможностью бронирования». То есть один отель за раз. Если клиент хочет «3 дня в Праге, потом 5 дней в Карловых Варах с трансфером и экскурсией» — этим занимается человек-агент вручную, иногда по полдня.

Tour Builder — это технология автоматической сборки сложных туров, основное конкурентное преимущество платформы Vitiana.

Tour Builder позволяет собирать тур из модулей:

• размещение в отеле (можно несколько отелей последовательно);
• переезды между сегментами (автомобиль, поезд, перелёт, водный транспорт);
• экскурсии и активности;
• услуги (гид, виза, страховка);
• аренда транспорта;
• страхование путешествия;
• произвольные пользовательские блоки (то, что агент добавляет вручную);
• информационные блоки (текст, заметки в программе тура).

Tour Builder проверяет, что компоненты совместимы между собой:

• даты не пересекаются;
• города и регионы соответствуют (трансфер действительно из одного города в другой);
• количество мест в размещении соответствует количеству пассажиров в трансфере;
• общая цена считается корректно с учётом скидок на пакет.

Tour Builder работает в двух режимах:

1. Vitiana собирает свои собственные туры — для продажи через сайт vitrip.store. Например, готовая программа «Прага + Карловы Вары + экскурсия в Кутна-Гора, 8 дней».
2. Партнёры с платным доступом собирают свои туры — корпоративные службы путешествий, белые-лейбл-витрины, специализированные туроператоры используют наш Tour Builder для создания собственных продуктов.

Возможность собирать сложные туры через программный интерфейс (API) — это редкое свойство на рынке. Большинство конкурентов имеют только базовое бронирование отдельных отелей или авиабилетов.

Кто заказчики и партнёры платформы

Платформа Vitiana обслуживает четыре основных типа покупателей:

Покупатель 1. Туристические агентства

Малые и средние агентства в Украине, Чехии, Польше, Казахстане. Они:

• получают рабочий кабинет;
• ищут предложения, формируют коммерческие предложения для клиентов;
• собирают сложные туры через Tour Builder;
• бронируют, ведут историю, формируют отчётность по своим продажам;
• платят подписку и комиссию с продаж.

Покупатель 2. Технические партнёры с платным API

Это разработчики и компании, которые встраивают данные и возможности Vitiana в свои собственные продукты:

• белые-лейбл-витрины для частных компаний;
• корпоративные службы путешествий;
• специализированные туроператоры с собственным брендом;
• крупные конкурирующие площадки, использующие Vitiana как дополнительный источник данных;
• метаsearch-сервисы;
• стартапы в смежных областях (программы лояльности, корпоративные тревел-приложения).

Они получают:

• программный интерфейс к платформенному слою;
• песочницу для разработки и тестирования;
• готовые тарифные пакеты с прозрачной ценой;
• партнёрскую аналитику;
• сертификацию для перехода в боевой режим;
• круглосуточную поддержку (на старших тарифах).

Они платят:

• по динамическому тарифу — стоимость зависит от реальной нагрузки, которую партнёр создаёт на платформу.

Покупатель 3. Конечные клиенты собственных сайтов Vitiana

Сайт vitrip.store — это собственная B2C-витрина платформы для конечных туристов. Они покупают туры напрямую у Vitiana, и Vitiana получает обычную туристическую маржу.

Vitrip.store работает одновременно как:

• источник дохода (собственные продажи);
• демонстрация возможностей платформы для технических партнёров (партнёр видит, что можно построить на нашем API).

Покупатель 4. Крупные корпоративные клиенты (Enterprise)

Крупные туристические сети, корпоративные службы путешествий международных компаний, авиакомпании-агенты могут заключать индивидуальные контракты на:

• выделенную инфраструктуру;
• расширенный уровень обслуживания (SLA);
• персонального инженера сопровождения;
• кастомные коммерческие условия (revenue-share, гибридные модели).

Этот сегмент развивается на третьей-четвёртой фазе зрелости платформы.

География первой волны

Платформа выходит на рынок последовательно. Первая волна — это страны, рынки которых мы знаем и где у нас есть базовое supplier-покрытие через поставщиков:

• Украина (UA) — основной начальный рынок;
• Чехия (CZ) — второй рынок, входной EU-юрисдикции;
• Польша (PL) — расширение в EU;
• Казахстан (KZ) — расширение на восток.

Платформа поддерживает основные региональные языки и валюты:

• украинский, русский, английский, в перспективе чешский, польский — рабочие языки;
• евро - как основная валюта, украинская гривна, чешская крона, польский злотый, казахстанский тенге, доллар США — рабочие валюты конвертации.

Дальнейшее расширение по географии — на третьей-четвёртой фазах зрелости.

Чем платформа Vitiana отличается от Booking.com, Expedia и других

Booking.com, Expedia, Airbnb, Trivago — это B2C-витрины (продают конечным клиентам). Они хорошо известны, у них огромный маркетинговый бюджет, и на их территории конкурировать с ними напрямую — экономически неоправданно.

Vitiana работает в другом сегменте:

• основная монетизация — через B2B-доступ к платформе (продажа API);
• собственная B2C-витрина (vitrip.store) — это вспомогательный канал и демонстрация, не основной;
• ключевое преимущество — Tour Builder, которого в нужном виде нет ни у одного крупного конкурента;
• ключевая география — восточная Европа и Казахстан, где Booking и Expedia слабее представлены в B2B-сегменте.

Прямые конкуренты по сегменту B2B-API:

• TravelgateX (международный) — крупный, но не специализирован на восточной Европе и не имеет Tour Builder в формате модульного API;
• HotelBeds Apitude (международный) — большой, но фокусирован на отелях, без полноценного Tour Builder;
• Sabre, Amadeus — глобальные распределительные системы, но они работают в основном с авиакомпаниями и крупными корпоративными клиентами, для малого и среднего B2B-сегмента слишком сложны и дороги;
• Региональные конкуренты в восточной Европе — есть, но они либо только агентские платформы, либо без Tour Builder, либо без серьёзной технологии.

Главное отличительное предложение Vitiana:

• единственная платформа в восточной Европе, специализированная на B2B-API marketplace для туристической индустрии с модульным Tour Builder;
• открытая для самостоятельной интеграции (партнёры регистрируются и интегрируются сами, без длительных переговоров);
• прозрачная динамическая тарификация (партнёр видит реальную стоимость и предсказывает счёт);
• готова обеспечить соответствие требованиям регуляторов нескольких стран одновременно.

Как платформа зарабатывает — три источника дохода

Источник 1. Собственные продажи через vitrip.store

Это обычная B2C-маржа: турист покупает тур или отель на сайте, Vitiana получает разницу между ценой поставщика и ценой клиента. Размер маржи — стандартная отраслевая, динамически настраиваемая по сегментам.

Источник 2. Партнёры с платным API — главный долгосрочный источник

Партнёр платит платформе за доступ к платформенному слою, а не за «количество отелей». Тариф зависит от реальной нагрузки, которую партнёр создаёт:

• объём поисковых запросов;
• объём созданных коммерческих предложений (quote);
• объём бронирований;
• сложность запросов (узкая или широкая география, простые или сложные фильтры);
• использование «дорогих» поставщиков (некоторые поставщики имеют высокие лимиты вызовов или платные API);
• использование машинного обучения (рекомендации, ранжирование, динамическое ценообразование);
• использование Tour Builder (тяжёлая операция);
• объём данных, которые партнёр хранит у нас.

Тарифные уровни:

Уровень	Для кого	Что включено
Free	Разработчики, оценивающие платформу	Песочница с реалистичными тестовыми данными, ограниченный объём для тестирования
Starter	Малые партнёры	Боевой доступ с минимальными квотами, базовый набор поставщиков, стандартная поддержка
Professional	Растущие партнёры с реальным объёмом	Расширенные квоты, полный набор поставщиков, доступ к Tour Builder, партнёрская аналитика, повышенный SLA
Enterprise	Крупные корпоративные клиенты	Гарантированная мощность, кастомные коммерческие условия, выделенная инфраструктура (на четвёртой фазе), персональный инженер сопровождения

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

Источник 3. Туристические агентства — рабочая платформа

Агентство платит за рабочий кабинет на платформе:

• подписка на месяц/год;
• комиссия с продаж;
• опциональный платный доступ к Tour Builder.

Размер подписки и комиссии — зависит от тарифного уровня агентства и объёма продаж.

Цепочка ответственности — кто отвечает за что

Платформа работает по классической модели агрегатора с гибридной структурой ответственности:

поставщики (отели, авиакомпании, экскурсии)
   ↓ инвентарь, цены, обещания исполнения
   
платформа Vitiana
   ↓ нормализация, проверка качества, ответственность перед поставщиком, частичная ответственность перед клиентами
   
покупатели платформы (агентства, технические партнёры, vitrip.store)
   ↓ доступ к платформенному слою, ответственность перед своими клиентами
   
конечные клиенты
   ↓ оплата, потребление туристического продукта

Кто за что отвечает:

• Поставщики отвечают за фактическое исполнение туристической услуги (отель открыт, номер забронирован, перелёт совершён).
• Vitiana отвечает за корректное представление данных поставщиков своим покупателям, своевременную обработку бронирований, корректные взаиморасчёты с поставщиками, целостность платформы.
• Покупатели платформы (партнёры, агентства) отвечают за своё представление данных конечным клиентам, маркетинг, обслуживание клиентов, обработку платежей (если они принимают деньги напрямую) и информацию для своих клиентов.
• Конечные клиенты отвечают за корректные данные при бронировании, оплату, соблюдение условий поставщика.

В зависимости от тарифа партнёра возможны разные модели приёма платежей:

• Платформа сама принимает платёж от конечного клиента (актуально для собственного канала vitrip.store и для агентств с базовым тарифом без своей платёжной системы).
• Партнёр сам принимает платёж (актуально для крупных B2B-партнёров со своей платёжной инфраструктурой). Партнёр получает счёт от платформы за платформенные услуги.
• Гибрид — для разных продуктов разные модели.

В каких странах работаем — соответствие требованиям

Платформа изначально проектируется с учётом регуляторов в каждой целевой стране:

• Общий регламент защиты данных (GDPR, регламент EU 2016/679) — обязателен для всех граждан EU (Чехия, Польша, обширная EU-аудитория). Защищает персональные данные конечных клиентов.
• Директива EU о пакетных туристических продуктах (Package Travel Directive 2015/2302) — применяется к турам из нескольких компонентов в EU. Требует страхования финансовой несостоятельности (insolvency protection), полного информирования клиентов перед заключением договора, ответственности за исполнение.
• Маржинальный режим НДС для туроператоров (TOMS) — особый налоговый режим для трансграничных туристических продуктов в EU.
• Стандарты безопасности платежей (PCI DSS) — при приёме платежей картами.
• Усиленная аутентификация клиентов (PSD2 SCA) — при онлайн-платежах в EU.
• DAC7 и Digital Services Act (DSA) — обязательства платформ по отчётности и прозрачности.
• AML/KYC (Anti-Money Laundering / Know Your Customer) — проверка партнёров на признаки отмывания денег.
• Налоговые режимы Украины и Казахстана — отдельные от EU, требуют отдельного учёта и отчётности.
• Локальная защита прав потребителей — каждая юрисдикция имеет свои особенности (сроки возврата, обработка споров).

Все требования встраиваются в платформу как стандартный набор, не как «потом разберёмся». Это значительная часть инвестиций в разработку, но обеспечивает работу платформы без юридических проблем.

Чего платформа сознательно не делает

Чтобы границы продукта были честными:

• Платформа не конкурирует напрямую с Booking.com за конечных клиентов. Vitrip.store — собственный канал и демонстрация, не основной источник дохода.
• Платформа не подражает структуре одного поставщика. Внутренние данные платформы организованы по собственной модели; поставщики переводятся в эту модель адаптерами. Это означает, что любой поставщик может быть отключён или заменён без переделки платформы.
• Платформа не делает «белый-лейбл-сайт под ключ» для каждого партнёра. Партнёр получает API и инструменты; собственный сайт партнёр строит сам, на нашем API.
• Платформа не принимает на себя обязательство партнёра перед его клиентами. Если партнёр продаёт через свой канал и принимает платёж, ответственность перед его клиентами лежит на партнёре. Это нормальная практика B2B-distribution.

Реалистичные сроки

Этапы развития

Платформа развёртывается по фазам с метрическими и доменными триггерами перехода — не по календарю.

Фаза	Длительность от старта	Что происходит
Фаза 1 — Запуск (Bootstrap)	0-8 месяцев	Сборка ядра платформы, разработка каноничной модели, прототип подключения поставщиков, инфраструктура минимальная
Фаза 2 — Изоляция сервисов (Service isolation)	8-16 месяцев	Раздельная инфраструктура для разных контуров, запуск партнёрского API в боевом режиме, первые платные партнёры
Фаза 3 — Зрелая платформа (Production-capable)	16-30 месяцев	Полная зрелая архитектура, полная география, машинное обучение в действии, premium-партнёры
Фаза 4 — Глобальное расширение (Multi-region и enterprise)	30+ месяцев	Многорегиональная инфраструктура, enterprise-тенанты с выделенной инфраструктурой, расширение в новые географии

Что нужно для успеха

Для того, чтобы платформа достигла зрелости и окупаемости:

1. Архитектурная дисциплина. Все принципы (правило "0", развитие без деградации, тезисное обоснование, удержание контекста) — соблюдаются на протяжении всей разработки.
2. Партнёрская стратегия. Параллельно с разработкой ведётся работа с потенциальными партнёрами: формирование тарифов, юридические договоры, программа сертификации. Без потока партнёров технология не окупается.
3. Юридическая поддержка нескольких юрисдикций. Соответствие требованиям регуляторов EU, Украины, Казахстана требует внимания и квалифицированного юриста.
4. Дисциплина фазового развёртывания. Не пытаться сразу строить всё одновременно. Каждая фаза достигается по триггерам, не по календарю.

Открытые вопросы для решения заказчика

Эти вопросы требуют решения владельца платформы или совета директоров. От них зависит конечная стоимость, сроки и архитектурные приоритеты.

1. Какой бюджет реально доступен на первые 12-24 месяца? Финансовый вопрос не рассматривается в этом документе, но обязательно должен быть проработан.
2. Сколько крупных партнёров планируется привлечь к моменту фазы 3? От этого зависит, насколько быстро нужна инфраструктура уровня enterprise.
3. Какова стратегия маркетинга и продаж B2B API? Платформа технически готова, но требуется план привлечения партнёров.
4. Кто принимает платежи от конечных клиентов на собственном канале vitrip.store? Платформа сама как merchant-of-record (требует регистрации и сертификации) или внешний платёжный сервис?
5. Какие конкретные партнёрские тарифы (цены) запускаются на старте? Архитектура поддерживает динамическую тарификацию; конкретные цены — коммерческое решение.

Связанная документация

Документы для общего понимания

• Главная архитектурная ось (overview/index.md) — для тех, кто хочет глубже разобраться в архитектуре.
• Манифест переосмысления платформы (overview/platform-vision-and-manifest.md) — формальное переосмысление роли платформы.
• Архитектурный якорь и бизнес-модель (overview/architectural-anchor-and-business-model.md) — детальное обоснование выбора стратегии.

Документы для технического читателя

• Платформа как продукт (overview/platform-as-product.md) — атрибуты B2B SaaS-продукта.
• Каноничная доменная ось (overview/canonical-domain-spine.md) — ключевые сущности.
• Поверхности взаимодействия (overview/layers.md) — каналы взаимодействия.
• Ось данных и интеллекта (overview/data-and-intelligence-spine.md) — события, машинное обучение, эксперимент.
• Операционная ось (overview/operational-spine.md) — масштабирование, надёжность, инциденты.

Документы для технического подрядчика

• Техническое задание для подрядчика — в development/technical-specification-for-development-contractors.md (создаётся параллельно с этим документом).
• Дорожная карта инфраструктурного масштабирования — в operations/scaling-and-packaging-roadmap.md.

Уточнение под Фазы 4–10 (28.04.2026) — отражение текущей архитектурной картины

Документ опубликован 26.04.2026. После Фаз 4–10 архитектура расширена существенно. Краткое резюме текущего состояния:

Текущая архитектурная картина

6 каноничных архитектурных осей (overview):

1. Каноничная доменная ось — 7 групп сущностей (canonical master / supplier-derived / operational offer / transactional / composition / governance / identity);
2. Поверхности взаимодействия — 6 surface contracts (Internal / Agency / Partner API / B2C / S2S / Tour Builder Closed) + ortogonal taxonomy 6 client surfaces (см. clients.md);
3. Платформа как продукт — 4 tier model (Free/Starter/Professional/Enterprise) с dynamic pricing;
4. Ось данных и интеллекта — 5 компонентов (events / DWH / ETL / ML / A/B), first-class с фазы 1;
5. Операционная ось — 8 принципов (эластичность, фазовая упаковка, managed services, открытые стандарты, DR, observability, инциденты, релизная дисциплина);
6. Связь с реализацией — мост между target архитектурой и working home-to-go-api.

Каноничные операционные стадии

Согласно development/roadmap.md:

• Stage 0 — Architectural baseline (100% закрыт);
• Stage 1 — Implementation baseline (следующий шаг);
• Stage 2 — Controlled internal platform;
• Stage 3 — Controlled external beta;
• Stage 4 — Production-capable baseline (SOC 2 Type 1);
• Stage 5 — Controlled scale (SOC 2 Type 2);
• Stage 6 — Multi-region + Enterprise + ISO 27001.

Ключевые архитектурные правила

5 каноничных правил-законов в development/:

• Закон 00000 — платформа главенствует над поставщиками (highest priority);
• Современные лучшие практики верхнеуровневых платформ;
• Эластичное масштабирование и упаковка по фазам;
• Развитие без деградации;
• Тезисное обоснование архитектурных решений.

Уточнение выполнено через no-destruction.