Інтеграція 1С-Бітрікс із системою бронювання Shelter

Подвійне введення даних, розсинхронізація завантаження, втрата бронювань — це стандартна ситуація, коли хостел використовує Shelter окремо від сайту на 1С-Бітрікс. Менеджер вручну переносить інформацію, не бачить єдиної картини, а при скасуванні в PMS дізнається про це випадково. За статистикою Shelter, понад 40% хостелів втрачають бронювання через ручне введення. На одному з наших об'єктів з 30 номерами ми скоротили час обробки заявки з 15 хвилин до 2. Це дозволяє ресепшн обслуговувати до 60 гостей на годину замість 10. Ми вирішили цю проблему для десятків об'єктів: наша інтеграція пов'язує PMS і сайт в єдину систему. Економія часу персоналу сягає 30%, а вартість рішення окупається за 2–3 місяці. Вартість інтеграції стартує від 600 доларів, а економія на ручній праці сягає 1200$ щомісяця для об'єкта на 30 номерів. Зв'яжіться з нами — отримайте консультацію щодо вашого об'єкта.

API Shelter: що потрібно знати

Shelter надає REST API. Базовий URL: https://api.shelter-pms.ru/v2/. Авторизація — Bearer-токен у заголовку. Інтеграція базується на асинхронній архітектурі з використанням черг повідомлень (RabbitMQ) для гарантованої доставки даних. Ключові ендпоінти:

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

Ліміт запитів: 120 на хвилину — у 2 рази більше, ніж у TravelLine (60). Пропускна здатність API Shelter у 2 рази вища за аналогічну у TravelLine. Тому навіть 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) за допомогою HMAC-SHA256, визначає тип події та оновлює замовлення в Бітрікс. Критична подія — 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" 

Що входить у вартість

– Розробка API-клієнта для Shelter – Мапінг номерів між системами – Синхронізація доступності – Обробка бронювань (створення, зміна, скасування) – Інтеграція webhooks – Документація (схеми, інструкції) – Навчання персоналу роботі з системою – Місяць технічної підтримки після запуску

Ми пропонуємо інтеграцію під ключ: від аналізу до запуску. У вартість входить документація, налаштування та місяць підтримки. Напишіть нам — оцінимо ваш проект безкоштовно. Рішення підходить для готелів, які використовують Бітрікс24 або 1С-Бітрікс. Ми спеціалізуємося на інтеграції Бітрікс із PMS-системами: понад 10 років досвіду, понад 100 проєктів. Shelter — одна з найгнучкіших і доступних платформ для хостелів. Зв'яжіться з нами — ми підготуємо індивідуальне рішення.