Календарь Airbnb не синхронизируется? 7 причин, почему iCal-фид устаревает

Прошлой зимой мой календарь на Booking.com тихо перестал подтягивать блокировки из Airbnb. Никакой ошибки — ни письма, ни красной плашки. Импорт просто замёрз во вторник, и я заметил это только когда гость из Лиона забронировал неделю, уже занятую на Airbnb. Фид не был «сломан» — по крайней мере так, как это признал бы интерфейс. Он устарел. А устаревание — единственный сбой, о котором iCal никогда не предупреждает.

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

Почему iCal замолкает, а не ломается

Синхронизация по iCal — это забор данных, а не их доставка. Когда вы «связываете» Airbnb с Booking.com, ни одна из платформ не открывает другой живой API. Принимающая платформа просто скачивает публичную ссылку .ics по собственному таймеру — раз в несколько часов — и перезаписывает свои импортированные блокировки тем, что нашла.

У такой схемы есть скверный побочный эффект. Если ссылка источника перестаёт отвечать — неверный URL, источник на минуту лёг, источник сменил ссылку, — принимающая сторона не показывает сбой. Она оставляет последние удачно скачанные данные и пробует снова на следующем цикле. С точки зрения интерфейса всё в порядке. Календарь по-прежнему показывает блокировки — просто застывшие во времени.

Настоящее API-соединение выдало бы 401 или 404, который вы бы увидели. iCal не выдаёт ничего. В самом протоколе (RFC 5545) нет канала доставки и нет стандартного сигнала «фид мёртв», который крупные платформы показывали бы хосту. Поэтому сбой невидим — пока второй гость не забронирует даты, которые другая платформа считает свободными.

Единственная цифра, которая важна: время последней синхронизации

Прежде чем менять хоть один URL, посмотрите на одно число: когда этот фид последний раз успешно импортировался?

• Airbnb: Calendar → выберите объект → Availability → Sync calendars → в разделе Imported calendars у каждого фида написано, как давно он обновлялся.
• Booking.com: экстранет → Calendar & Pricing → Sync calendars → в разделе импорта для каждого подключённого фида указано время последней синхронизации.

Теперь читайте так:

Эта цифра — вся суть. Девять из десяти паник «у меня не синхронизируется календарь» — это либо здоровый фид внутри обычного окна, либо фид, который мёртв уже несколько дней, а на дату никто не посмотрел.

Семь причин, почему фид устаревает — и решение каждой

1. Ссылку источника сбросили (причина номер один)

Симптом: фид работал, а теперь «последняя синхронизация» — несколько дней назад или «никогда». Причина: кто-то нажал Reset URL на стороне источника — вы, соведущий или вы сами после истории с утёкшей ссылкой. Сброс мгновенно убивает старый URL, а принимающая сторона всё ещё держит отменённый. Все запросы с тех пор молча падали с 404.

Решение: скопируйте текущую ссылку экспорта у источника, удалите мёртвый импорт на принимающей платформе и добавьте заново. Потом проверьте ссылку (см. проверку из причины 5). Относитесь к ссылке экспорта как к паролю: сброс после утечки — правильный шаг, но в тот же день нужно обновить её везде, где она импортируется.

2. Вы внутри обычного окна обновления (ложная тревога)

Симптом: вы заблокировали даты на Airbnb 40 минут назад, а Booking.com всё ещё показывает их свободными. Причина: ничего не сломано. Booking.com тянет фид каждые 2–6 часов и просто ещё не запускал очередной цикл.

Решение: подождите. Если для Booking.com прошло больше 6 часов или для Airbnb больше 4 — тогда считайте это реальной проблемой и идите по списку дальше. Это самая частая ложная тревога: хост смотрит на принимающую сторону десять минут и решает, что синхронизация сломана, хотя она просто спит до следующего опроса.

3. Платформа тихо выкинула фид после серии сбоев

Симптом: фид работал, потом источник на день прилёг (профилактика, временно смененная ссылка, которую вы уже починили), и теперь он не восстанавливается, хотя URL снова живой. Причина: после нескольких подряд неудачных запросов некоторые платформы вообще перестают опрашивать фид и не включают его обратно сами. Счётчик ошибок защёлкнулся.

Решение: удалите импорт и добавьте ровно тот же URL заново. Это сбрасывает счётчик, и платформа начинает опрашивать с нуля. Живой URL, который не синхронизируется больше суток, — почти всегда именно этот случай.

4. На стороне источника iCal отключён

Симптом: ссылки экспорта вообще нет, или панель Sync calendars у источника пропала. Причина: у аккаунтов на контракте с channel manager или API-партнёром iCal выключен по умолчанию — платформа считает источником правды API. У некоторых типов объектов на Booking.com (классические отели, в отличие от посуточной аренды) iCal не появляется никогда.

Решение: если вы подписали партнёрский/API-договор — так и должно быть, синхронизация идёт по API, а не по iCal. Если ничего не подписывали, а iCal просто исчез — напишите в партнёрскую поддержку, для объектов посуточной аренды его включают обратно.

5. Фид импортируется, но блокировки не появляются

Симптом: «последняя синхронизация» свежая — пару минут назад, — а даты всё равно показаны свободными. Причина: импорт прошёл, но у событий нет статуса «занято», либо импортёр читает только однодневные события DATE, а источник отдал события со временем. С Airbnb и Booking.com это редкость (они отдают аккуратные однодневные блокировки), а вот с самописными или экзотическими фидами — обычное дело.

Решение: откройте .ics в текстовом редакторе и посмотрите на одно VEVENT. Вам нужны однодневные блокировки вида DTSTART;VALUE=DATE:20260714 на ожидаемые даты. Вот быстрая проверка для любой iCal-ссылки:

1. Вставьте ссылку экспорта в адресную строку браузера.
2. Живой фид либо скачает файл .ics, либо покажет текст, начинающийся с BEGIN:VCALENDAR.
3. Страница с ошибкой, экран входа или пустой ответ означают, что ссылка мёртвая — вернитесь к причине 1.

6. Смещение часового пояса сдвигает каждую блокировку на день

Симптом: блокировки импортируются, но встают на день не туда — день выезда заблокирован, день заезда свободен, или наоборот. Причина: фид, который отдаёт события со временем и с TZID, а принимающая сторона читает их в UTC, может перекинуть блокировку через полночь. Старт в 23:00 по местному времени становится следующим днём в UTC.

Решение: предпочитайте однодневные блокировки (VALUE=DATE) событиям со временем. Крупные платформы так и делают; если фид ваш (самохостинг, кастомный экспорт) — отдавайте даты, а не дату со временем. Если вы вынуждены потреблять фид со временем, сдвиг ровно на день — это и есть подсказка: не тратьте час на обвинение ссылки.

7. Вы упёрлись в лимит слотов импорта

Симптом: не получается добавить ещё один импортированный календарь, или самый новый молча игнорируется. Причина: большинство платформ ограничивают число импортированных фидов примерно пятью на объект. Разместитесь на Airbnb, Booking.com, Vrbo, Expedia и своём прямом сайте — и слоты кончатся быстро, ведь каждая платформа должна импортировать все остальные.

Решение: сверните сетку в «звезду». Вместо того чтобы N платформ импортировали N−1 остальных, сделайте по одному промежуточному фиду на платформу: каждая платформа импортирует хаб, хаб импортирует каждую платформу. Две платформы — это четыре прямые ссылки; хаб делает из них две. Это же и причина, по которой прямой перекрёстный импорт тихо перестаёт масштабироваться после двух платформ — подробнее в статье как избежать двойных бронирований.

Когда виновата платформа, а не вы

А теперь честная часть. Даже если все семь причин исключены и каждый фид здоров, собственный опрос принимающей платформы — это пол, ниже которого не прыгнуть. Booking.com тянет фид каждые 2–6 часов, и вы на это никак не влияете.

Промежуточный слой решает половину проблемы. Открытый инструмент вроде RentTools — или ваш собственный cron — опрашивает исходные фиды каждые 10 минут, так что хаб узнаёт о новой броне на Airbnb за десять минут, а не за часы. Чего он не может — заставить Booking.com тянуть из хаба быстрее, чем Booking.com сам захочет. Единственное, что обходит цикл опроса целиком, — это API в реальном времени, который Airbnb и Booking.com продают только сертифицированным PMS за $100–300 в месяц.

Для одного-трёх объектов из-за окна обновления спать спокойно вполне можно. Причины устаревания выше — сброшенная и не обновлённая ссылка, фид, который платформа тихо выкинула, — приводят к куда большему числу двойных бронирований на малых масштабах, чем когда-либо приведёт цикл в 2–6 часов. Если вам нужна не диагностика, а полная настройка с нуля, начните с гайда как бесплатно синхронизировать календари Airbnb и Booking.com.

Одно мнение, не нейтральное

Перестаньте считать окно обновления главным врагом. Эффектная проблема «iCal не в реальном времени» приводит к меньшему числу двойных бронирований на малых масштабах, чем скучная рутина: ссылка, которую кто-то сбросил и забыл обновить, фид, который платформа тихо перестала опрашивать. И то и другое невидимо, пока вы не посмотрите на время последней синхронизации, — так посмотрите. Раз в неделю открывайте каждый импортированный фид и читайте одну дату. Двадцать секунд привычки ловят те тихие сбои, которые интерфейс с радостью от вас прячет.