Bnovo, TravelLine, Shelter и OPERA Cloud: сценарии интеграции

Bnovo, TravelLine, Shelter CLOUD и OPERA Cloud можно подключать к внешнему гостиничному контуру, но не одним и тем же способом. Практический выбор начинается не с логотипа PMS, а с конкретного маршрута: получить бронь, заметить изменение, передать анкету, назначить номер, провести check-in, сохранить платёж или остановить доступ после отмены.

По публичной документации на 3 августа 2026 года у всех четырёх систем есть интеграционные механизмы, но различаются доступ, события и допустимая обратная запись. Bnovo разделяет односторонний API «Старт» и двусторонний «Профессионал»; TravelLine WebPMS публикует методы чтения и операционных действий; Shelter CLOUD даёт отдельный API-модуль, тестовый Swagger и ограничивает операции с самой бронью; OPERA Cloud использует платформу OHIP с отдельным onboarding, приложениями и Business Events. Наличие метода в документации не доказывает, что он включён в тариф объекта или уже реализован в Concierge.

Короткий ответ: какую PMS выбрать для интеграции

Если PMS уже используется, обычно безопаснее не менять её ради одной функции. Сначала определите минимальный набор полей и действий, получите тестовый доступ и прогоните одну бронь через полный жизненный цикл. Если PMS только выбирают, сравнивайте не абстрактную «открытость», а подтверждённый контракт выбранного сценария.

Важно: таблица сравнивает публичные интеграционные контракты, а не качество PMS и не фактическую глубину каждого подключения Concierge. Для Bnovo, TravelLine и Shelter основной контекст — российские средства размещения; OPERA Cloud — глобальная платформа Oracle. Договоры, доступность функций, локализацию, хранение данных и требования вашей страны нужно проверять отдельно.

Как проводилось сравнение

Мы проверили открытые страницы и руководства самих поставщиков 3 августа 2026 года. Для Bnovo использован релиз API «Профессионал» от 5 февраля 2026 года; для TravelLine — актуальные страницы Universal WebPMS API и настройки webhooks; для Shelter CLOUD — руководство API и опубликованные production/test Swagger-стенды; для Oracle — документация OHIP, OPERA Cloud 26.1, Business Events, Streaming и onboarding.

Все эти источники vendor-authored: они описывают заявленные возможности собственных продуктов. Это не независимый benchmark. Мы не подключались к аккаунтам отелей, не проверяли закрытые тарифы, индивидуальные доработки, скорость поддержки, полноту данных и production-качество всех четырёх систем. Поэтому в статье нет рейтинга, универсального победителя и выдуманных процентов успешности.

Сначала опишите сценарий, потом выбирайте API

Сценарий 1. Получать новые и изменённые брони

Минимальный контракт включает внешний ID, объект, даты, статус, категорию и назначенный номер, контакты, состав гостей, источник бронирования и момент изменения. Одного списка броней мало: интеграция должна отличать создание, изменение, отмену, no-show, переселение и восстановление отменённой записи.

Событие лучше воспринимать как сигнал перечитать запись, а не как полный снимок. Shelter прямо описывает Reservation webhook, который передаёт ID изменённой брони: гости, начисления или платежи могли поменяться, поэтому полные данные запрашиваются отдельно. Oracle Business Events также настраиваются по модулям, действиям и выбранным data elements; если поле не включено в конфигурацию, его не будет в событии.

Сценарий 2. Запускать сообщения, анкету и самостоятельное заселение

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

Маршрут онлайн-регистрации требует отдельного решения по документам и персональным данным. TravelLine публично перечисляет операции сохранения документа, адреса рождения и изображения документа. Shelter описывает работу с гостями и дополнительными полями. Возможность метода не разрешает автоматически собирать всё доступное: нужны минимизация, роли, сроки хранения и законное основание для конкретной страны. Практический контур разобран в статье «Онлайн-регистрация и KYC гостя».

Сценарий 3. Назначать номер и проводить check-in/out

TravelLine документирует назначение номера, заселение и выселение. Shelter CLOUD — check-in/out по конкретной брони и управление дополнительными полями, но не создание или изменение самой брони через основной API. В OPERA Cloud операции и Business Events зависят от подключённых API, модулей, прав и конфигурации объекта. В Bnovo точный список методов нужно брать из доступа выбранного уровня API, а не из общего маркетингового описания.

Даже доступный метод записи нельзя включать «на будущее». Для каждого действия нужны владелец поля, допустимое исходное состояние, идемпотентный ключ, правило повтора и компенсирующая операция. Если check-in прошёл в PMS, а локальный ответ потерялся по тайм-ауту, слепой повтор не должен создавать противоречие.

Сценарий 4. Синхронизировать платежи и начисления

TravelLine перечисляет чтение платежей и операции платежа/возврата. Shelter CLOUD публикует группы Payments и Accruals. Bnovo API «Профессионал» заявляет работу с платежами. Но PMS не обязана быть авторитетным источником состояния эквайринга: успешный HTTP-ответ, запись в PMS и фактический платёж у провайдера — разные события.

Сначала определите, кто подтверждает деньги, затем решите, какой факт записывается в PMS. Холд, списание, отмена холда и возврат нельзя сводить к одному статусу «оплачено». Подробное сравнение есть в статье «Онлайн-платежи: преимущества и настройка».

Сценарий 5. Выдавать цифровой доступ

PMS обычно подтверждает действующее проживание, даты и назначенный номер. Платёжный сервис подтверждает обязательное условие оплаты или депозита. Система доступа подтверждает выпуск и отзыв credential. Только сочетание этих фактов позволяет передать PIN-код или цифровой ключ.

Отдельная страница Shelter описывает API для интеграции электронных замков, но это специализированный контракт, не доказательство совместимости с любой замковой системой. У других PMS также нужно проверять конкретное расширение или внешний контур. Схему выбора физического доступа смотрите в материале «Электронный замок, keybox или механический ключ».

Bnovo: начните с нужного уровня доступа

Bnovo в релизе от 5 февраля 2026 года разделяет два уровня. «Старт» предназначен для односторонней выгрузки базовых данных через GET. «Профессионал» заявлен как двусторонний: GET, PUT, POST и webhooks для гостей, платежей, отчётности и дополнительных услуг; по умолчанию он включён в тариф «Максимум».

Для первого пилота это даёт простой выбор. Если цель — уведомления по броням, не начинайте с максимальных прав: подтвердите чтение, изменения и отмены. Если нужен write-back, выберите одно действие и получите его точную спецификацию. Маркетинговые примеры Bnovo про чат-бота, продажи услуг и аналитику принадлежат поставщику и не являются доказанными результатами вашего объекта.

Что запросить у Bnovo

• активный уровень API и точный список методов;
• схему webhook-событий, подпись, повторы и окно хранения;
• тестовый объект без реальных персональных данных;
• правила изменения гостя, платежа и дополнительной услуги;
• лимиты, журнал запросов и процедуру восстановления после сбоя.

TravelLine WebPMS: широкий контракт, зависящий от компонентов

Universal API TravelLine WebPMS публично перечисляет брони, профили гостей, платежи, начисления, счета и номера. Среди действий указаны назначение номера, check-in, check-out, платёж, возврат и сохранение данных документа. Для доступа нужна действующая подписка TL: WebPMS по тарифу «СТАНДАРТ» или выше.

Webhooks настраиваются в личном кабинете по модулям и категориям: бронирования, заезды, уборка, гости и другие доступные компоненты. TravelLine требует доступный HTTPS endpoint и ответ 200 OK, но публичная страница настройки не превращает webhook в гарантированную доставку. Интеграции всё равно нужны идемпотентность, журнал, повторное чтение и периодическая сверка.

Что проверить у TravelLine

• какие компоненты и категории событий включены у конкретного объекта;
• разделены ли ключи и права для теста и production;
• какие поля обязательны при назначении номера и check-in/out;
• как API сообщает конфликт уже изменённой брони;
• что произойдёт с событиями во время недоступности endpoint.

Shelter CLOUD: тестовый Swagger и явные ограничения записи

Shelter публикует production и test Swagger для ShelterCloudAPI. Для доступа объекту нужно купить и активировать API-модуль, затем получить Bearer token у поддержки. Методы сгруппированы по броням, гостям, комнатам, платежам, начислениям, услугам, справочникам и webhooks.

Ключевое ограничение нужно вынести в требования: основной API позволяет читать брони, работать с гостями, check-in/out и дополнительными полями, но не создаёт, не изменяет и не отменяет брони. Для создания частично используется отдельный Booking Widgets API. Reservation webhook передаёт ID записи, после чего потребитель должен запросить полные данные.

Что проверить у Shelter

• какая операция относится к ShelterCloudAPI, а какая — к отдельному API;
• какие поля брони меняются косвенно через гостя, начисление или платёж;
• как повторно забрать полное состояние после нескольких быстрых webhook;
• достаточен ли test stand для полного сценария check-in/out;
• какие методы включены в тариф объекта и какие считаются индивидуальными.

OPERA Cloud: интеграционная платформа, а не один ключ API

Oracle Hospitality Integration Platform требует отдельного onboarding. Партнёр регистрирует приложение, получает sandbox environment, gateway и credentials. Для production создаётся отдельное приложение; Oracle прямо указывает, что non-production application не получает доступ к production environment. При OAuth-аутентификации используются client ID/secret, application key, scope, enterprise ID и hotel ID.

Business Events можно настраивать по модулям, действиям и data elements. Для брони доступны события создания и изменения; официальные сценарии также описывают check-in, check-out, отмену, no-show и восстановление. Oracle рекомендует Streaming там, где важна оперативность, и polling для менее срочных случаев. Это мощная модель, но она требует управления offset, переподключением, порядком обработки и полным чтением ресурса после события.

Что проверить у OPERA Cloud

• есть ли у объекта OPERA Cloud Foundation и подключение OHIP;
• кто владеет partner onboarding и production application;
• какие API plans, modules, scopes и hotel IDs разрешены;
• какие data elements реально включены в Business Event;
• как consumer хранит offset, восстанавливается после разрыва и обрабатывает HTTP 429.

Сравнение по сценариям

Формулировка «проверять» означает не отсутствие функции, а недостаток публичного подтверждения для универсального обещания. Закрытый контракт, новый релиз или индивидуальная интеграция могут давать больше возможностей. Зафиксируйте это приложением к техническому заданию.

Пилот на одной тестовой брони

1. Создайте изолированную бронь. Не используйте реального гостя. Зафиксируйте внешний ID, объект, даты, категорию, тариф и участников.
2. Получите её в интеграции. Сравните каждое обязательное поле с PMS, а не только факт появления записи.
3. Измените даты и контакт. Старое сообщение и срок доступа должны отмениться или пересчитаться.
4. Назначьте другой номер. Проверьте mapping комнаты и отзыв старого credential.
5. Добавьте второго гостя. Анкеты и контакты участников не должны смешаться.
6. Выполните разрешённое действие записи. Например, сохраните тестовый статус или проведите check-in; повторите тот же запрос с тем же idempotency key.
7. Сымитируйте недоступность. Отключите consumer в тестовой среде, затем подтвердите повтор, polling или сверку после восстановления.
8. Отмените бронь. Будущие сообщения, платёжные требования и доступ должны остановиться.
9. Проверьте журнал. Для каждого действия нужны source ID, время, версия payload, результат, retry и причина ручной эскалации.

Критерии готовности к production

Частые ошибки

Считать логотип PMS подтверждением всех модулей

Интеграция бронирований не доказывает обратную запись платежа, документа, check-in или замкового доступа. Для каждого модуля нужна отдельная матрица полей и действий.

Путать webhook с полным состоянием

Событие может содержать только ID или выбранные изменённые поля. После него часто нужно перечитать ресурс, сравнить версию и применить идемпотентное изменение.

Давать приложению максимальные права

Права записи повышают цену ошибки. Начните с read-only, затем добавляйте по одному write-сценарию с владельцем и аудитом.

Тестировать только новую бронь

Главные дефекты проявляются при изменении дат, переселении, втором госте, отмене, no-show, повторном событии и восстановлении после простоя.

Принимать vendor-страницу за SLA

Публичная документация подтверждает заявленную функцию на дату проверки. Доступность, лимиты, поддержку и ответственность фиксируют договор, техническая спецификация и пилот.

FAQ

Какая из четырёх PMS лучше для Concierge?

Универсального ответа нет. Если PMS уже работает, оцените конкретный маршрут и стоимость доступа к API. При новом выборе сравните обязательные сценарии, права, события, тестовую среду, договор и возможности восстановления, а не число логотипов.

Если у PMS есть webhooks, polling больше не нужен?

Нет. Webhook сокращает задержку, но не заменяет повторное чтение, идемпотентность и периодическую сверку. Потребитель должен восстановиться после пропуска или недоступности.

Можно ли начать только с чтения броней?

Да. Для уведомлений и части CJM этого часто достаточно. Это снижает риск, но ручная работа останется там, где результат нужно записывать обратно в PMS.

Можно ли загружать документы гостей во все четыре PMS?

Публично подтверждённые методы различаются. TravelLine прямо перечисляет сохранение документных данных, Shelter — работу с гостями и дополнительными полями, для Bnovo и OPERA нужен точный контракт. В любом случае метод API не заменяет правовое основание и минимизацию данных.

Подтверждает ли эта статья готовую интеграцию Concierge с Shelter или OPERA Cloud?

Нет. Статья подтверждает публичные возможности PMS. Готовность конкретной связки подтверждают договор, mapping, тестовые credentials и успешный пилот одной брони.

Зачем отдельное production-приложение для OPERA Cloud?

Oracle разделяет non-production и production applications. Это помогает изолировать доступ и жизненный цикл credentials; точный onboarding выполняется через OHIP Developer Portal.

Что считать успешным пилотом?

Не просто HTTP 200. Бронь должна пройти создание, изменение, переселение, гостя, разрешённую запись, отмену, повтор и восстановление после сбоя; итоговые состояния сверяются в авторитетных системах.

Источники и границы применимости

• Bnovo — API «Старт» и API «Профессионал», релиз 5 февраля 2026 года; проверено 3 августа 2026 года. Vendor-authored описание, включая примеры результата.
• TravelLine — Universal API WebPMS и настройка webhooks, проверено 3 августа 2026 года. Vendor-authored документация; состав зависит от подписки и компонентов.
• Shelter CLOUD — руководство по PMS API, включая production/test Swagger, ограничения брони и Reservation webhook; проверено 3 августа 2026 года. Vendor-authored документация.
• Oracle — OHIP partner sandbox, Business Events, Streaming API и OPERA Cloud 26.1 event configuration, проверено 3 августа 2026 года. Глобальная vendor-authored документация.

Материал не является договорной спецификацией, юридической консультацией или доказательством production-совместимости. Публичные API меняются; перед проектом сохраните версии документов и согласуйте точный набор методов, права, географию обработки данных и ответственность сторон.

Следующий шаг

Возьмите одну реальную операцию — например, «изменение брони → новое сообщение → новый номер → отзыв старого доступа» — и заполните четыре колонки: источник факта, метод или событие PMS, действие Concierge и владелец исключения. Так выяснится, где есть рабочий контракт, а где пока только название интеграции.

Если нужно сопоставить вашу PMS с анкетой, оплатой, сообщениями и доступом, оставьте заявку на техническую консультацию Concierge Online. На встрече можно собрать минимальную матрицу и план тестовой брони без доступа к production-данным на первом шаге.