Skip to documentation content

Channels & Calendar

Avoid and recover from channel overbooking

Reduce stale-calendar and duplicate-source risk, then preserve evidence and apply the approved recovery path when channel inventory conflicts.

iCal is periodic, so it cannot provide a real-time delivery guarantee. Reduce risk by mapping each feed to the correct room type, setting a quantity that does not exceed physical inventory, monitoring health and never importing the same reservation through both API and iCal.

Prevent conflicts

  • Keep the export URL and imported source label documented per room type.
  • Use Sync now after a controlled OTA change, then check Last success.
  • Keep failed or stale sources visible; a safe failure preserves the last known good blocks rather than silently reopening inventory.
  • Review the Booking Calendar for Website, API and iCal source labels before accepting a manual reservation.
  • Treat checkout as unoccupied and verify the hotel’s channel cut-off policy.

If dates conflict

  1. Stop repeated submissions and do not release an external block manually.
  2. Search Hotel Booking → Bookings for an existing website or API booking before creating a replacement.
  3. Record the room, stay interval, source label, source ID, booking code, quantity, last successful sync and redacted health reason.
  4. Contact the authoritative OTA to confirm or relocate the external guest.
  5. Reconcile only through a successful feed snapshot or the existing API workflow. Verify the refreshed inventory afterward.

External blocks cannot be confirmed, cancelled, paid or refunded locally. Do not edit dates or totals in the database to make the calendar look clear. Treat an overbooking as a release-blocking incident and preserve logs for support.

Was this article helpful?

Your feedback helps us improve the documentation.