Чотири ключові можливості
Section titled “Чотири ключові можливості”| Можливість | Що це означає | Чому продукти без цього зупиняються |
|---|---|---|
| Актуальні тарифи та наявність | Поточні ціни та що реально доступне для бронювання, по датах | Кешовані тарифи не працюють при підтвердженні і підривають довіру |
| Створення бронювання | Створення реального резервування, яке отримує готель | Без цього ви лише реферальне посилання, а не продукт |
| Оплата | Прийом грошей у процесі бронювання | Перенаправлення на інший сайт вбиває конверсію |
| Підтвердження та вебхуки | Повідомлення гостя, готелю та вашої системи про подію | Інакше виникають проблеми з підтримкою і звіркою |
Більшість “готельних API”, які знаходить розробник, охоплюють перше і іноді друге. Транзакція — це складна частина, і саме вона визначає, чи є у вас продукт.
Чий контент ви інтегруєте?
Section titled “Чий контент ви інтегруєте?”Це питання визначає все, що йде далі. Контент, перепроданий через ланцюжок, має націнку у тарифі, застарілу наявність і немає прямого зв’язку з готелем для запитань про бронювання. Контент, що надходить безпосередньо від готелю, має власний тариф готелю, актуальну наявність і готель, який знає про бронювання.
Для будь-чого, де мандрівник порівнюватиме з офіційним сайтом готелю — а це більшість випадків — контрольований готелем контент уникає незручного моменту, коли ваша ціна гірша.
Хто є продавцем у записі
Section titled “Хто є продавцем у записі”Якщо ви створюєте бронювання готелів самостійно, стати продавцем у записі означає брати на себе відповідальність за оплату, повернення коштів, обробку податків і часто ліцензію турагентства в кожному ринку.
У Wink готель залишається продавцем у записі, і оплата збирається для готелю, тому інтегратор не успадковує цю відповідальність. Угоди про продавця у записі доступні для API-інтеграцій, де партнер дійсно має приймати оплату, і цей шлях має власні вимоги до ліцензування.
Три рівні інтеграції
Section titled “Три рівні інтеграції”- Веб-компоненти. Вставте пошук, список номерів або оформлення бронювання на існуючу сторінку. Без бекенду; найменший контроль над макетом.
- REST API. Повний контроль над пошуком, тарифами, створенням бронювання та підтвердженням, аутентифікація через OAuth2. Використовуйте, коли процес бронювання є частиною вашого продукту.
- MCP сервер. Ті ж можливості для AI-агентів, щоб помічник міг шукати, ціноутворювати і завершувати бронювання замість передачі користувача на сайт.
Ці три варіанти не виключають один одного — продукт часто використовує компоненти для маркетингової поверхні і API для основного процесу.
Що будувати спочатку
Section titled “Що будувати спочатку”- Пошук і ціноутворення для одного міста і одного діапазону дат. Отримайте реальні тарифи перед дизайном.
- Створіть одне тестове бронювання повністю, включно з оплатою і підтвердженням.
- Підпишіться на
booking.createdта події скасування перед тим, як будувати UI. - Рано визначте модель атрибуції — контекст джерела має передаватися з бронюванням, інакше звіти будуть здогадками.
- Обробляйте випадки помилок: втрата наявності між котируванням і бронюванням, відмова оплати, часткові повернення.
Ціноутворення, яке має знати розробник
Section titled “Ціноутворення, яке має знати розробник”API Consumer і Booking Engine безкоштовні. Partner API включає безкоштовний місячний ліміт 10 000 готельних ночей, потім оплачується за одиницю. Підтверджені бронювання несуть 1,5% платформену комісію готелю плюс вартість обробки картки, а 10% стандартна комісія застосовується, коли бронювання зроблено через ваш продукт — так інтегратор заробляє, а не платить.
Поширені помилки
Section titled “Поширені помилки”- Робота на кешованих тарифах. Вони виглядають добре в розробці, але не працюють у продакшені.
- Передача оплати через редирект. Кожна передача втрачає бронювання.
- Ігнорування вебхуків до запуску. Звірка стає ручною роботою.
- Стати продавцем у записі без потреби. Це рішення про ліцензування і відповідальність, а не лише технічне.
- Не передавати контекст джерела. Атрибуцію неможливо відновити пізніше.