Bulk Date Blocks: Closing Availability Across Every Channel at Once

Blocking a date on one calendar is easy. The unit only stays unsold if the other three also heard about it.

Last updated: September 23, 2026

A bulk block closes a run of nights in one action rather than thirty. That's exactly why it deserves a procedure. Four channels hold four copies of the same decision, and a block is real only on the copies that accepted it. This guide covers where the gap opens between one calendar and four, and the order to push a block in. It sets out what counts as confirmation, what to do the moment a single channel refuses, and why reopening dates is the step most often left half finished.

Key Takeaways

• A block is four decisions, not one. Closing a night on your side is a request until each channel holds it.
• Push in a fixed order. Range first, then existing bookings, then the block, then the read-back.
• The read-back is the confirmation. What each channel currently holds is the only thing worth trusting.
• A refusal is a containment job. Close that night by hand in the refusing channel first and diagnose after.
• Reopening is two operations. Availability back and rate back; doing only the first leaves the date looking open and selling nothing.

Why a block placed in one place isn't a block everywhere, and where the gap opens

A bulk block feels like a single switch, and on your side it is. Behind it, four separate copies of your calendar each have to accept the same instruction. And one of them declining doesn't undo the other three. That's the shape of the problem: not a failure, but a partial success that looks complete from where you're standing.

The gap opens in a handful of predictable places.

Dates you sell outside the four connections. Airbnb, Booking.com, Agoda and Trip.com are the channels that sync. Anything you sell through beyond those has no connection carrying your block, so those calendars stay open unless somebody closes them by hand. If a unit is listed anywhere else, that listing's the first place to look when a blocked night sells.

A range that already contains a booking. Close ten nights and one of them holds a reservation you forgot about. The outcome then depends on how that channel treats a conflict: some apply the block around the booking, some decline the whole range. Either way, what you get isn't what you asked for.

Minimum-stay rules sitting across the boundary. Closing two nights inside a window where a three-night minimum applies leaves a fragment that can't be sold but isn't closed either. It reads as open on the channel. And as unavailable to every guest who tries.

The wrong unit, or the wrong room type. With more than one unit, a block applied to the wrong row is the most common version of this mistake. It produces an empty-looking calendar in the wrong place, while the unit you meant to close stays on sale.

None of these announce themselves. The only reliable way to find them is to look at what each channel is holding rather than at what you sent.

The order to push a block in, and the acknowledgement worth waiting for

Four steps, always in this order, because each one removes a class of failure that the next can't fix.

One, fix the range in property time. Write the first and last night down, inclusive of both ends, in the timezone the property runs in. A block that ends at midnight in the wrong timezone clips a night at one end, and that night is the one that sells.

Two, read what is already on those dates. Every booking, every hold, every night closed for another reason. If the range isn't empty, decide now what should happen to what is on it — not after the push.

Three, push the block once, from the source calendar. One action covering the whole range, not thirty single-night edits. Many small edits give you many chances to miss one and no way to tell which.

Four, read it back per channel. This is the acknowledgement worth waiting for, and it's the step people replace with a guess. What a channel is currently holding is a fact; a sent confirmation is a claim about your own side. Nobody can promise how long the gap between the two takes, so don't build a routine around a clock — build it around the read. One calendar showing all four connections carries each channel's source rate and source status per row. That turns the read-back into one look instead of four logins.

What to do when one channel refuses the block, and how to stop a double booking

Refusal rarely arrives as a refusal. It arrives as a range that applied on three channels and not the fourth, and you notice when a booking lands on a night you had closed.

Contain it before you diagnose it. The night is on sale at that channel right now, and every minute spent working out why is a minute in which it can sell. Log into that channel's own admin and close the date there directly. Nothing about that step is elegant, and it's the only step that stops the double booking immediately.

Then diagnose, in this order, because the causes aren't equally likely. Read the refusing channel's current state first. Availability and rates for all four connections sit on one grid at localsbnb.com, with each row showing that channel's source rate and source status. So you can see whether it's holding a booking, a stale rate or nothing at all before you choose a fix.

What you find	What it usually means	What to do next
A booking already on part of the range	The channel protected the guest	Decide whether the block moves or the booking does, then re-push once
A minimum stay that conflicts with the boundary	The rule blocked the fragment	Adjust the range or the rule, then re-push
A rate plan closed over those dates	Availability was never the obstacle	Reopen or re-point the plan, then re-push
Nothing obvious	The instruction did not land	Re-push once and read back; if it still fails, close by hand for the whole window

Two habits matter here. Never retry twice without reading back between attempts, because you can't tell a second failure from a first one that simply hadn't finished. And when a night is genuinely at risk, close the whole window on that channel rather than the single date. One extra closed night costs you a booking you chose to give up; one open night can cost you a guest standing at the door.

Reopening dates: the reverse operation that's easier to get wrong

Closing is one operation. Reopening is two, and the second is the one people forget.

Availability comes back first: the nights are open again. Rate has to come back with them. A reopened night with no rate behind it isn't sellable. But on your calendar it looks exactly like an open night that nobody happens to want. Check that the night carries the price you meant before you assume the unit is back on the market.

Restrictions are the third thing, and they survive reopening more often than rates do. A minimum stay, a closed-to-arrival day or a booking window set during the block is still sitting there. It quietly rejects the enquiries the reopened night was supposed to attract.

The other way reopening goes wrong is arithmetic in the wrong direction. Maintenance overruns, so you reopen the range minus two nights, and the range you reopen is one night longer than you meant. The unit is on sale for a day the work is still happening, which is a worse failure than being closed an extra day.

One check covers all of it. Pick one date inside the reopened window, on each channel, and read it the way a guest would. Is the night open? Does it carry a price? Can it actually be booked for the length of stay you expect? Three questions, one date, and you'll know whether the reopen finished.

FAQ

Should I block dates on each channel separately, or push one block?

One push from the source calendar, then a read-back per channel. Blocking by hand in four places is four chances to mis-key a date, and it hides the one piece of information you need: which channel didn't accept the instruction.

How long does a block take to reach every channel?

Long enough that you should never rely on a clock. Make the read-back the step, not a wait — what each channel currently holds is a fact you can act on, and an estimate isn't.

What if a blocked night sells anyway?

Close the remaining nights on that channel by hand first, then deal with the booking. Containment comes before diagnosis every time, because a night that's still on sale can sell twice more while you investigate.

A block that three channels accepted isn't a block; it's a night waiting for a guest to find it. Push once from one source calendar. Read every channel back rather than trusting the send. Contain a refusal by hand before you investigate it, and treat every reopen as availability plus rate plus restrictions. If you'd rather do the read-back in one place, all four channel calendars sit on one grid at localsbnb.com.

---

Availability behaviour, restrictions and how a conflict is resolved differ by platform and change over time; read the current state of each channel you sell on before relying on any of this.