Синхронизация календарей занятости: интеграция с каналами, которые не дают API

TL;DR. Часть каналов не даёт партнёрского API — единственный машиночитаемый выход у них это письмо-уведомление. Сервис разбирает такие письма, нормализует их в общий формат и сводит в один Google Calendar. Следующий этап — автоматическая блокировка занятых дат в остальных каналах.

Ситуация: интеграции нет, а двойная запись есть

Занятость ведётся сразу на нескольких площадках. Каждая ведёт свой календарь и не знает о занятости в соседних. Как только дата занята в одном канале, её надо немедленно закрыть в остальных — иначе один и тот же слот уходит дважды.

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

Задача

1. Собрать записи со всех каналов в один календарь, включая каналы без API.
2. Обрабатывать не только подтверждения, но и отмены — освобождённые даты должны возвращаться в доступность.
3. Подготовить механику обратной записи: закрывать занятые даты в остальных каналах.
4. Сделать добавление нового канала предсказуемой работой, а не отдельным проектом.

Что сделали

Каждый канал получает свой адаптер, потому что машиночитаемый выход у всех разный. Один присылает вложение в формате ICS, другой — только HTML-письмо, где данные записи лежат в вёрстке шаблона. Отмена у одного канала приходит отдельным типом письма, у другого — тем же шаблоном, отличаясь темой.

Адаптер приводит письмо к общему виду: объект, даты начала и окончания, статус, идентификатор записи. Нормализованные записи записываются в единый Google Calendar — он и становится источником правды по занятости.

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

Результат

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

Ключевые технические решения

1. Письмо как интеграционный контракт. Когда API нет, письмо-уведомление остаётся единственным машиночитаемым выходом. Это не обходной путь, а осознанный выбор источника данных — и он требует адаптера на канал, потому что формат у каждого свой.
2. Отмена — полноценный сценарий, а не исключение. Пропущенная отмена держит свободные даты закрытыми и обходится дороже, чем пропущенное подтверждение. Обработка отмен заложена в каждый адаптер с самого начала.
3. Очередь блокировки отделена от сценариев автоматизации. Задания на закрытие дат ставятся в очередь независимо от того, реализован ли уже сценарий для конкретной площадки. Когда сценарий появится, накопленные задания выполнятся без переделки логики.
4. Честный статус по каналам. Каждый канал имеет своё состояние готовности: где-то работает полный цикл, где-то только приём записей. Смешивать их в один общий статус — способ незаметно потерять записи.

Частые вопросы

Зачем парсить письма, если у площадок есть API?

У части площадок партнёрского API нет вовсе — ни выгрузки записей, ни управления доступностью. Письмо-уведомление остаётся единственным машиночитаемым выходом. Там, где API есть, используется он.

Насколько надёжен разбор писем?

Формат письма задаёт площадка, и он меняется. Поэтому адаптеры разделены по каналам и по типам событий: изменение шаблона у одной площадки ломает один адаптер, а не весь сбор.

Это применимо только к записям на объект?

Нет. Схема «письмо как источник данных, нормализация, единый календарь или база» переносится на любой процесс, где контрагент не даёт интеграции: уведомления маркетплейсов, подтверждения перевозчиков, выгрузки от поставщиков.

Что было бы дальше

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

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