Перейти к содержимому
Русский

API для разработчиков

ЗачемДать разработчику отеля или интегратору отправную точку: что это за API, где его спецификация и как устроен доступ.
КомуРазработчику, который подключает к HotelsCalendar свою систему; владельцу — чтобы показать подрядчику.
Что получитсяПонимание поверхности API — какие данные им можно достать — и процесса получения доступа: токен и базовый URL.
ОграниченияЭто отправная точка, а не справочник методов: полный перечень — в спецификации; технические лимиты не публикуются.

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

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

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

Полное описание API — OpenAPI-спецификация, файл openapi.yaml: в ней перечислены все методы — что каждый принимает и возвращает — и модели данных. Спецификация сгруппирована примерно в 24 тематических раздела.

Открывается и скачивается спецификация по базовому URL API — адресу, который выдаётся вместе с доступом. Она — источник истины по возможностям: всё, что в ней описано, API умеет; чего в ней нет — API не обещает.

Доступ к API — по токену: персональному ключу, который передаётся с каждым запросом. По токену API понимает, от какого объекта идёт запрос и что этому доступу разрешено.

Токен и базовый URL приходят вместе — при подключении (как его оформить — ниже). Относитесь к токену как к паролю: он открывает данные объекта, поэтому хранится на вашей стороне и не публикуется.

  • Своя аналитика. Брони выгружаются в вашу BI-систему или таблицу — и считаются там так, как вам нужно, без ручного экспорта каждый месяц.
  • Синхронизация с внутренними системами. Учётная программа или сервис отеля получает брони и изменения из PMS — и данные не расходятся между системами.
  • Мини-сервисы и виджеты. Небольшой инструмент поверх данных отеля — внутренняя страница для персонала, сводка для управляющего, — который берёт данные из PMS напрямую.

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

  • Технические лимиты API — частота запросов, объёмы выгрузок — в этой статье не публикуются.
  • Перечень возможностей — только спецификация: методы и модели описывает openapi.yaml, статья ничего сверх неё не обещает.
  • Как API меняется со временем — совместимость версий, порядок уведомлений об изменениях, — эта страница не обещает: условия проговариваются при подключении.
  • Пошаговых примеров с кодом здесь тоже нет — их роль выполняет спецификация.
  1. Напишите нам через страницу «Контакты» на сайте HotelsCalendar: опишите задачу — что за система подключается и какие данные ей нужны.
  2. Мы пришлём токен и базовый URL API.
  3. Дальше — по спецификации: найдите методы под свою задачу и подключайте свою систему.

Если вопрос не про разработку, а про настройку отеля — начните со страницы поддержки.

  • Поддержка и контакты — куда и как писать команде: через поддержку начинается и доступ к API.
  • Глоссарий терминов — расшифровка отельных терминов, которые встретятся в данных: бронь, доступность, тариф, заселение.