API-интеграции в турбизнесе: пять вопросов до подключения к поставщикам

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

По каким критериям сравнивать интеграции

Список функций почти ничего не даёт: поиск, бронирование и справочники есть у любого API. Полезнее сравнивать четыре вещи.

• Где хранятся данные. У TravelLine, например, два типа интеграции Partner API: в первом данные хранит платформа, во втором канал продаж. От этого зависит, сколько модулей придётся строить и кто отвечает за актуальность и защиту данных.
• На ком договор и доступ. Собственный договор, статус субагента и партнёрский ключ дают разные права и разную зависимость от посредника.
• Как получить доступ. Заявка и пилот, ключ, песочница с последующей сертификацией различаются и по срокам, и по трудоёмкости.
• Что обменивается. Только цены и наличие или ещё бронирования, статусы, квоты и документы.

Сравнить слои по цене, SLA и лимитам запросов не получится: в проверенных материалах таких данных нет. Их придётся запрашивать у поставщиков.

Отели и каналы продаж: пилот, сертификация и кто держит данные

Подробнее всего в открытых источниках описано подключение к TravelLine. Partner API состоит из Search API (цены и доступность номеров), Reservation API (автоматическое бронирование проживания и услуг) и Content API (описание объектов). Чтобы канал быстро узнавал об изменениях, он может получать события через вебхуки: система сама присылает уведомление, а не ждёт очередного запроса.

Порядок такой. В течение 2–3 рабочих дней после заявки TravelLine связывается с каналом продаж, согласует дату добавления в Channel Manager (систему, через которую отель управляет наличием и ценами в каналах) и открывает канал пилотному отелю. Основная работа приходится на канал продаж, а сроки подключения зависят от его технической готовности и уточняются у TravelLine. Эти условия относятся только к подключению канала к TravelLine, переносить их на другие интеграции нельзя.

Ostrovok (Emerging Travel Group) устроен иначе. Компания публикует B2B API со специальными ставками, Affiliate API, Content API и Midoffice API, а в документации описаны песочница, руководство по интеграции и сертификация перед выходом в production. Выходит два подхода: подключение через посредника с пилотом и самостоятельная интеграция, где перед запуском нужно пройти проверку на стороне поставщика.

Про охват. Фраза о том, что Channel Manager работает со 130+ каналами продаж, включая Ostrovok, Pegas и Avito, — позиция TravelLine о собственном продукте. Независимо она не проверялась, поэтому нужные вам каналы лучше сверить напрямую.

Туры: ключ партнёра, виджеты и процент с продаж

В готовых турах логика другая. API Level.Travel отдаёт цены туров онлайн, данные для виджетов, справочник стран, курортов и городов вылета. Его можно использовать для собственного поиска, мобильного приложения или SEO-страниц. Пилота здесь нет, нужен персональный API-ключ партнёра.

Есть и более лёгкие варианты: виджеты и XML-фиды. Но главное здесь экономика. По описанию партнёрской программы, доступ к ценам оплачивается процентом от прибыли с продаж, организованных через сервис. Точные условия не проверялись, их нужно уточнять у Level.Travel. Для агентства модель оплаты становится первым вопросом; в отельном слое она так остро не стоит.

Туроператоры тоже открывают доступ агентствам. У «Алеана», например, есть страница API для взаимодействия агентств с системой поиска и бронирования туров. О её функциях выводов не сделать: в открытых материалах сказано лишь, что такая страница существует.

Оператор и принимающая сторона: обмен заявками, квотами и статусами

Здесь интеграция связывает учётные системы, а не витрину с поставщиком. По описанию САМО-тур, в обмен входят новые бронирования, изменения и аннуляции, статусы по заявкам и услугам, каталоги цен, СПО, квоты и блоки, остановки продаж, справочники, ваучеры и документы, а также сообщения по заявкам. Обмен контролируется через журнал обмена.

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

Авиа: главный вопрос — договор

Сирена-Трэвел предоставляет XML-шлюз WS-Gate: через него агентство получает справочные данные и контент системы бронирования и продажи авиаперевозок. Для интернет-пункта продажи нужен собственный договор с оператором системы либо статус субагента агентства, у которого договор уже есть. Это самый наглядный пример вопроса о владельце договора и доступа: технически подключиться можно, но без нужного юридического статуса доступа не будет. Технических параметров шлюза в проверенных материалах нет, поэтому их здесь нет.

Персональные данные: где будут храниться данные туристов

Одно ограничение действует независимо от слоя: локализация персональных данных. По статье 18 152-ФЗ в редакции, которую показывает КонсультантПлюс, при сборе персональных данных граждан РФ, в том числе через интернет, их запись, систематизация, накопление, хранение, уточнение и извлечение должны идти с использованием баз данных на территории России. Исключения — случаи из пунктов 2, 3, 4 и 8 части 1 статьи 6.

Для выбора платформы это значит, что вопрос «где хранятся данные» нужно понимать буквально, а не как вопрос удобства. Если вы выбираете CRM, облачный сервис или зарубежную API-платформу, которые будут работать с данными клиентов и туристов, выясните, в какой стране эти данные физически окажутся. Правила локализации ужесточались. Размер ответственности мы не приводим: вторичные источники называют разные суммы, и их нужно сверять с текстом КоАП РФ, а не с пересказами. Подпадает ли ваш случай под исключения из статьи 6, лучше уточнить у юриста.

Что уточнить до подключения

Цены, SLA и технические лимиты API не проверялись. Условия TravelLine и оплаты Level.Travel — формулировки самих компаний, а «130+ каналов» и «меньше ошибок» — позиция вендоров. Всё это стоит получить письменно до начала работ.

Рейтинг поставщиков по этим данным не составить, так что практичнее идти по порядку вопросов:

1. Какой слой нужен в первую очередь: отели, туры, авиа или обмен с принимающей стороной.
2. Где будут храниться данные: у поставщика или у вас, как в двух типах Partner API.
3. На ком договор и доступ: свой договор, субагентство или партнёрский ключ.
4. Как выбранная схема хранения соотносится с требованием локализации по 152-ФЗ.
5. Какие цена, SLA и лимиты запросов прописаны у поставщика письменно.