Inventory tells you how many. Rate plans tell you at what price. Restrictions tell you under what conditions a booking can actually land. They are how you stop a sale, cap a stay, push back arrivals, or hide a rate plan from a specific channel.
What the layer covers
| Restriction | What it does |
|---|---|
| Stop-sale | Closes a date for a property, a room, a rate plan, or one room under one rate plan. No bookings, full stop. |
| Closed to arrival | Bookings cannot start on the date but stays passing through it are fine. |
| Closed to departure | Bookings cannot end on the date. |
| Minimum stay | A booking must include at least N nights. |
| Maximum stay | A booking cannot exceed N nights. |
| Day-of-week constraints | Specific days locked or required (e.g. Saturday-only stays). |
| Advance purchase | Booking must be made at least N days before check-in. |
| Per-channel exposure | A rate plan visible on one channel but not another. |
Each one is independent; you layer them as the situation needs.
A property connected to a channel manager takes its restrictions from the channel manager, as it does its prices and inventory. Adrasis shows them read-only; change them at the channel manager.
Stop-sale, the simple, common case
Stop-sale is the bluntest tool: this date, this room, this rate plan, closed. You use it when:
- The property is renovating and cannot accept guests on those dates.
- An event nearby is booking up the city; you stop external sales to manage walk-ins.
- A supplier is being flaky and you want to halt distribution until you sort it out.
Setting a stop-sale is one operation in the Console:
- Open the date range on the rate calendar.
- Drag-select the cells.
- Click Stop-sale; preview shows the affected cells, channels and existing bookings.
- Confirm.
The cell colour changes; outbound channels stop returning availability for that date; inbound bookings get rejected with a clean reason.
A stop-sale can be undone the same way, drag-select, Open for sale, confirm. Existing bookings are not affected.
Min and max stay
Stay restrictions cap the shape of bookable stays:
- Minimum stay 2 on Saturdays, common for weekend leisure properties.
- Minimum stay 3 in peak season, keeps short-stay bookings from blocking longer-stay revenue.
- Maximum stay 14 nights, for a property where longer stays need a different contract.
You set them on date ranges. The rate calendar shows the restriction next to the date; bookings that violate the restriction are rejected at the channel layer with a clear reason.
On the Rates screen, switch to the Status or Min Stay layer and select one night to close it or give it a minimum stay, or select several nights to change them together. On the Restrictions page, a start and an end date set every night between them.
Day-of-week constraints
Some properties only sell certain weekly patterns:
- Saturday-to-Saturday only, common for vacation rentals.
- No Sunday arrivals, for properties with light Sunday operations.
- Closed Monday–Wednesday, for seasonal operations.
Day-of-week constraints work alongside stop-sale and stay rules, a property might be Saturday-arrivals-only AND have a 7-night minimum stay; both apply.
Advance-purchase and lead-time
Time-shape rules:
- Advance purchase 7 days, book at least a week before check-in. Common for non-refundable rates.
- Same-day booking allowed, relax the rule for last-minute bookings.
These rules typically attach to a rate plan rather than to inventory, Non-Refundable Europe requires 7 days advance, Best Available Rate allows up to check-in.
Per-channel exposure
This is the restriction overlay that makes "publish selectively" possible:
- A rate plan that is public-only stays out of B2B channels.
- A rate plan that is B2B-only stays out of metasearch.
- A property that is direct-only does not surface on any outbound channel.
- A specific rate plan is excluded from one channel while remaining visible to others.
The overlay applies per (rate plan, channel) pair. You set it once; the platform honours it on every outbound message. Inbound messages from a channel for which a rate plan is not exposed simply do not produce updates on that rate plan.
Close one room under one rate plan
A rule you set on a rate plan applies to every room the plan is sold in. When only one room differs, give that room an exception. Hotel Sunrise sells seven rooms under Room only, refundable. A stop-sale for the Double Room on 10 October under that plan closes the Double Room for it, and the other six rooms stay on sale. Non-refundable, when it follows the status of Room only, refundable, is closed in the Double Room and open in the other six. A channel manager that sends a stop-sale for one room and one rate does exactly this.
- An exception can only tighten. It can close a night, add a minimum stay or shorten a maximum stay for that room. It cannot reopen a night the plan closes, and a smaller minimum stay on the exception does not lower the plan's minimum. To close every room but one, put exceptions on the other rooms.
- Where you set it. On the Rates screen, edit a cell on the room's row for the plan. On the Restrictions page, choose a rate plan and, under Room (optional), a room. Adrasis AI Operator takes a room together with a rate plan.
- Which rooms an edit changes. The Apply to plan control in the header of a plan's row changes every room of the plan. A cell of that row changes that room only and is marked Room exception. The room row itself stays for physical closures such as a renovation.
- A room that is not linked to the plan cannot take an exception, because the room is not sold under that plan.
For child prices and extra-adult amounts of one room see Rate plans.
How restrictions stack
The property, the room, the rate plan and a room exception all apply to a booking attempt, and when several restrictions apply, the strictest one wins:
- 5 rooms available, 3-night minimum, advance purchase 7 days → a 2-night booking 6 days out is rejected (two restrictions both fail).
- Stop-sale active → rejected, no need to evaluate anything else.
- All restrictions pass → booking lands on the cell.
The platform tells the channel, and ultimately the traveller, which restriction blocked the booking, and whether the property, the room or the rate plan closed the date, so retries can be intelligent.
Bulk operations
Restrictions are where bulk operations earn their keep. A few examples that come up regularly:
- "Stop-sale all rooms at Hotel Sunrise from June 1 to 8 for the renovation."
- "Apply a 3-night minimum stay on Saturdays in July across all the Antalya beach properties."
- "Close the Best Available Rate to arrivals on Sundays in August."
- "Remove the metasearch exposure for the member rate plans across the whole organization."
All of these can be done from the Console manually or expressed to Adrasis AI Operator in one sentence with preview before commit.
What about overrides
Restrictions can be overridden by humans for specific bookings, the front desk takes a 1-night booking even though the rate plan says 2-night minimum, or sales overrides a stop-sale for a known guest. Overrides are recorded explicitly:
- The operator who overrode the rule.
- The booking that benefited.
- The original restriction.
- The reason (free-text, captured at the time).
This keeps restrictions clear: the rule is real, and any exception remains visible to the team.
Where to next
- The rate plans these restrictions live on → Rate plans
- The inventory side → Inventory
- Promotions layered on top of unrestricted cells → Promotions & discounts
- Per-cell change history → Cell history