Availability calendar sync: integrating with channels that offer no API

TL;DR. Some channels offer no partner API — their only machine-readable output is a notification email. The service parses those emails, normalises them into a common format and merges them into a single Google Calendar. The next stage is automatically blocking booked dates in the remaining channels.

Situation: no integration, but double bookings all the same

Availability is managed across several platforms at once. Each keeps its own calendar and knows nothing about bookings on the others. The moment a date is taken in one channel it has to be closed in the rest, or the same slot gets sold twice.

The standard answer is an API integration. The problem is that some channels simply don't provide a partner API: no booking export, no availability management. What's left is walking through each admin panel by hand after every booking.

Task

1. Gather bookings from every channel into one calendar, including channels without an API.
2. Handle cancellations as well as confirmations — freed dates have to return to availability.
3. Prepare the write-back mechanism for closing booked dates in the other channels.
4. Make adding a new channel predictable work rather than a project of its own.

What we built

Each channel gets its own adapter, because every one has a different machine-readable output. One sends an ICS attachment; another sends only an HTML email with the booking data buried in the template markup. One channel signals a cancellation with a separate email type; another uses the same template and changes only the subject line.

The adapter normalises the email into a common shape: property, start and end dates, status, booking identifier. Normalised bookings are written into a single Google Calendar, which becomes the source of truth for availability.

For channels where dates can only be closed through the admin panel, the write-back scaffolding is in place: a task queue, retries and conflict detection. The interface automation scripts for each platform are still in progress — that's the next stage.

Result

• Bookings from channels with no API land in the shared calendar automatically.
• Confirmations and cancellations are handled with equal reliability, so freed dates return to the calendar.
• One calendar as the source of truth, instead of a tour of several admin panels.
• The write-back queue is ready and accumulating jobs; they will run as soon as the script for a given platform is finished.

Key technical decisions

1. The email as the integration contract. With no API, the notification email is the only machine-readable output. That isn't a workaround but a deliberate choice of data source — and it needs one adapter per channel, because every format differs.
2. Cancellation as a first-class path, not an edge case. A missed cancellation keeps free dates closed and costs more than a missed confirmation. Cancellation handling is built into every adapter from the start.
3. The blocking queue is separate from the automation scripts. Jobs to close dates are queued regardless of whether the script for that platform exists yet. When it does, the accumulated jobs run without reworking the logic.
4. An honest status per channel. Each channel has its own readiness state: some run the full cycle, others only receive bookings. Merging those into one overall status is how you quietly lose bookings.

FAQ

Why parse emails if the platforms have an API?

Some platforms have no partner API at all — no booking export, no availability management. The notification email is the only machine-readable output. Where an API exists, we use it.

How reliable is email parsing?

The platform controls the email format, and it changes. That is why adapters are separated by channel and by event type: a template change at one platform breaks one adapter, not the whole collection.

Does this only apply to property bookings?

No. The pattern — email as data source, normalisation, one calendar or database — carries over to any process where a counterparty offers no integration: marketplace notifications, carrier confirmations, supplier exports.

What would come next

The immediate next stage is the automation scripts for blocking dates in the platforms' admin panels; the queue and conflict handling are already in place. After that, connecting the remaining channels and alerting on discrepancies between calendars.

If a process of yours depends on a counterparty that offers no integration, let's talk it through in 30 minutes.