Интеграция 1С-Битрикс с системой бронирования Shelter

Двойной ввод данных, рассинхронизация загрузки, потеря броней — это стандартная ситуация, когда хостел использует Shelter отдельно от сайта на 1С-Битрикс. Менеджер вручную переносит информацию, не видит единой картины, а при отмене в PMS узнаёт об этом случайно. По статистике Shelter, более 40% хостелов теряют бронирования из-за ручного ввода. На одном из наших объектов с 30 номерами мы сократили время обработки заявки с 15 минут до 2. Это позволяет ресепшн обслуживать до 60 гостей в час вместо 10. Мы решили эту проблему для десятков объектов: наша интеграция связывает PMS и сайт в единую систему. Экономия времени персонала достигает 30%, а стоимость решения окупается за 2–3 месяца. Свяжитесь с нами — получите консультацию по вашему объекту.

API Shelter: что нужно знать

Shelter предоставляет REST API. Базовый URL: https://api.shelter-pms.ru/v2/. Авторизация — Bearer-токен в заголовке. Ключевые эндпоинты:

• GET /rooms — список номеров с типами
• GET /availability — доступность по диапазону дат
• GET /tariffs — тарифные планы
• POST /bookings — создание брони
• PUT /bookings/{id} — изменение брони
• GET /bookings/{id} — статус брони

Лимит запросов: 120 в минуту — в 2 раза больше, чем у TravelLine (60). Поэтому даже 50 номеров синхронизируются без задержек. При крупных объектах используем пакетные запросы. Согласно документации Shelter API v2, это максимальная пропускная способность для стандартного тарифа.

Как работает синхронизация номерного фонда?

При первом запуске (или по требованию) загружаем полный справочник номеров из Shelter и создаём соответствующие элементы инфоблока в Битрикс. Маппинг хранится в таблице bl_shelter_room_map:

CREATE TABLE bl_shelter_room_map ( bitrix_element_id INT NOT NULL, shelter_room_id VARCHAR(64) NOT NULL, room_type VARCHAR(64), synced_at TIMESTAMP DEFAULT NOW(), PRIMARY KEY (bitrix_element_id) ); 

Это позволяет при синхронизации доступности обращаться к Shelter по shelter_room_id, а на сайте показывать данные через стандартный инфоблок Битрикс. Обновления происходят инкрементально — только изменившиеся позиции. Для объектов до 50 номеров полный цикл занимает менее 3 секунд.

Получение доступности

Агент запрашивает GET /availability?date_from=YYYY-MM-DD&date_to=YYYY-MM-DD раз в 15 минут. Ответ — матрица «дата × тип номера × количество свободных мест». Запрос охватывает 90 дней вперёд.

function SyncShelterAvailability(): string { $client = new ShelterApiClient(SHELTER_TOKEN); $dateFrom = (new DateTime())->format('Y-m-d'); $dateTo = (new DateTime('+90 days'))->format('Y-m-d'); $data = $client->get('/availability', [ 'date_from' => $dateFrom, 'date_to' => $dateTo, ]); foreach ($data['availability'] as $row) { \Bitrix\Main\Application::getConnection()->queryExecute( "INSERT INTO bl_shelter_availability (room_type_id, date, qty) VALUES (?, ?, ?) ON CONFLICT (room_type_id, date) DO UPDATE SET qty = EXCLUDED.qty, synced_at = NOW()", [$row['room_type_id'], $row['date'], $row['available']] ); } return __FUNCTION__ . '();'; } 

Создание и отмена броней

При подтверждении оплаты в Битрикс отправляем бронь в Shelter. Shelter возвращает booking_id, который сохраняем в UF-поле заказа UF_SHELTER_BOOKING_ID. При отмене заказа в Битрикс (событие OnSaleOrderCanceled или смена статуса через обработчик) делаем запрос PUT /bookings/{id} с полем status: cancelled. Если Shelter API недоступен в момент отмены — ставим задачу в очередь агента с повторными попытками. Среднее время выполнения бронирования — 0.8 секунды, отмены — 0.5 секунды.

Что происходит при отказе Shelter API?

API может быть временно недоступен. Мы предусмотрели очередь повторных попыток: если запрос не прошёл, он помещается в агент, который повторяет отправку каждые 5 минут до успеха. Максимальное количество попыток — 3, после чего задача помечается как ошибочная и отправляется уведомление администратору. На практике такая ситуация возникает реже чем в 1% случаев, но мы гарантируем сохранность данных.

Webhooks из Shelter

Shelter отправляет уведомления при изменении статуса брони в PMS (например, менеджер отменил бронь прямо в Shelter, минуя сайт). Настройка webhook — в разделе «Настройки → Интеграции» Shelter. Обработчик верифицирует подпись (X-Shelter-Signature), определяет тип события и обновляет заказ в Битрикс. Критичное событие — booking.cancelled: нужно освободить дату в локальном кэше и уведомить гостя по email через \Bitrix\Main\Mail\Event::send.

Передача гостевой информации

Shelter хранит профили гостей. При создании брони через сайт проверяем, есть ли гость с таким email в Shelter (GET /guests?email=...). Если есть — передаём guest_id. Если нет — Shelter создаёт профиль автоматически. Это упрощает работу ресепшн при повторных визитах: вся история гостя видна прямо в PMS.

Типичные ошибки при интеграции

curl -X GET "https://api.shelter-pms.ru/v2/availability?date_from=2025-01-01&date_to=2025-01-10" \ -H "Authorization: Bearer token" 

Документация, обучение менеджеров, поддержка в течение месяца после запуска.

Мы специализируемся на интеграции Битрикс с PMS-системами: более 10 лет опыта, свыше 100 проектов. Shelter — одна из самых гибких и доступных платформ для хостелов. Свяжитесь с нами — мы подготовим индивидуальное решение.