Every host who lists on more than one platform has the same fear: two guests, one apartment, same night. The usual explanation is "the sync was slow." That is almost never what happened.
Double bookings in a connected setup are rarely caused by a delay. They are caused by something overwriting a night that was already sold.
What actually happens when a booking arrives
When a guest books on Booking.com, the channel manager does not wait for your system to notice and then tell the other platforms to close the night. The channel closes it immediately, at the source, as part of accepting the booking.
By the time the reservation reaches your dashboard, the night is already unavailable everywhere. Your system is being informed, not asked.
This matters, because it means the danger window most people worry about — the seconds between a booking landing and your system hearing about it — is not the real risk. The channel already handled it.
The real risk is your own availability writes
If the platform closes the night on booking, how do two guests ever get the same night?
Because something re-opened it.
The dangerous action is not receiving a booking. It is pushing availability. Any process that sends "this room has N units free on this date" can overwrite a night the channel had already closed — and it will do so confidently, because it believes it knows the correct number.
The usual culprits:
- A bulk availability update over a date range that includes nights already sold.
- A calendar import from a third party whose view of your inventory is stale.
- Manual edits in a dashboard, where someone sets a month to "2 units available" without realising one is booked.
- A retry or replay of an earlier sync job carrying numbers that were correct when it was queued and wrong by the time it ran.
In each case the channel closed the night correctly and your own system re-opened it. The booking that follows is not a sync failure. It is an instruction the platform obeyed.
Why "rooms to sell" is not "rooms you own"
This is the single most common modelling mistake, and it causes overbooking on multi-unit properties specifically.
If you have 3 identical studios and 1 is booked for Thursday, the number you send for Thursday is 2, not 3. The field means free units, not total units.
Send 3 and you have just told the platform there is room for three more bookings on a night where only two exist. Nothing is broken; the platform sells what you offered. This is why a property with several identical units overbooks far more often than a single apartment — a single unit is 1 or 0 and hard to get wrong, while multi-unit inventory requires subtracting what is already sold on every single push.
How to tell which one bit you
When a double booking happens, the question to answer is not "was sync slow" but "what wrote to that night last."
- Check the order of events. If the second booking arrived after an availability push touching that date, the push is your cause.
- Check the range, not the date. Bulk updates are written as ranges. The damaging edit often targeted a different night and swept this one up.
- Check for repeats. A job that ran twice with stale numbers looks identical to a job that ran once — except the night re-opened after it was closed.
- Check multi-unit maths first. On a property with identical units, assume the free-versus-total error before anything more exotic.
What actually prevents it
Not faster syncing. Correct arithmetic and fewer writes.
- Never push a flat number across a range. Compute each night separately against what is booked on that night.
- Cap every push by real free capacity. The number sent should never exceed total units minus units already reserved for that date — enforced in the system, not remembered by a person.
- Do not mirror availability back from a booking webhook. The channel already closed the night. Writing your own number afterwards can only make it wrong.
- Treat manual calendar edits as the highest-risk action you have. They bypass every calculation the system would otherwise perform.
The counter-intuitive part
Most hosts, after an overbooking, ask for faster or more frequent syncing. That usually makes it worse: more writes mean more chances to overwrite a correctly closed night.
The safe setup writes less, and every write is capped by what is genuinely free. GateIn enforces that cap per night rather than trusting the number it was handed, which is why a bulk update across a month cannot re-open the three nights inside it that are already sold.