Sync Design Between a Channel Manager (Beds24) and Our Own Site

Introduction

If you run a vacation rental, the scariest thing that can happen is a double-booking — two parties booked for the same night. And with a whole-house rental, there's no other room to move anyone into. All you can do is call one of your guests and cancel on them, and your reviews will feel it.

This article walks through the big picture of the sync design that lets you sell the same property on your own website and on booking sites like Airbnb (OTAs) without inventory ever drifting apart.

Deciding Where the Source of Truth Lives

Our Own Site Holds No Inventory

The first thing we settled on was putting the source of truth — the one and only correct copy — for inventory, rates, and bookings on the channel manager side. The official site keeps no availability data in its own database; it asks, every single time it needs to know.

At first glance you might think "wouldn't a copy in our own database be faster?" But the moment you keep a copy, you inherit two hard questions: when do you sync it, and when the two disagree, which one is right? Narrowing the source of truth down to one turned out to be both the simplest and the safest option.

Our Database Only Tracks the State of the Integration

That doesn't mean our database sits empty. What it holds isn't the bookings themselves — it's how far along each integration is.

Details like addresses and estimated arrival times are deliberately never stored on our side — they pass straight through to the channel manager. What you don't hold can't leak. With personal data, "don't keep it" is very often the best safeguard available.

How We Work With the API

One Door In and Out

Code that talks to external APIs has a habit of spreading everywhere. On this project we set one rule up front: only a single file is allowed to talk to the channel manager.

The code that renders screens can't call the API directly, and neither can the payment code. Everything goes through that one door, and whatever comes back gets validated before it's used. With a single door, updating authentication or changing how errors are handled means fixing one place and having it take effect everywhere.

Handling Access Tokens

The Beds24 API works by exchanging a long-lived refresh token for an access token that's valid for 24 hours. We never persist the access token — it lives in the server's memory and refreshes itself automatically as expiry approaches.

Respecting Rate Limits

APIs cap how many calls you can make in a given window. If someone with bad intentions tinkers with the URL parameters and fires off a flood of searches, they can hit that ceiling and stop genuine guests from booking at all.

So we validate the inputs — nights, party size, how far ahead the dates are — on our own side before any API call goes out. Impossible requests get rejected before they ever reach the API. That single layer cuts wasted calls dramatically.

Three Sub-Topics

Sync design covers a lot of ground, so we dig into each piece in its own article.

Fetching Availability and Rates

Never sum daily rates yourself, and never display "sold out" when a fetch fails. The design principles for the display side are covered in "Showing Availability and Rates in Near Real Time".

Pushing Bookings and Preventing Double-Booking

The order in which you confirm a booking is what keeps accidents from happening. Hold the room first with an availability re-check, save the card last. The reasoning behind that order is in "A Booking Registration Flow That Prevents Double-Booking".

Syncing Changes and Cancellations

When a booking arrives via an OTA, or the operator shifts the dates on the channel manager side, how does the official site keep up? The combination of notifications and periodic reconciliation is covered in "Reliable Sync with Webhooks Plus Hourly Reconciliation".

Wrapping Up

Three ideas anchored the whole sync design with the channel manager.

1. One source of truth — inventory, rates, and bookings live on the channel manager; our site holds none of it
2. One door — all traffic to the external API funnels through a single place and gets validated before use
3. Decide what you won't hold — addresses and the like pass straight through instead of being stored, cutting off the leak risk entirely