# Stop-sale & restrictions

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, room, or 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.                     |
| **Lead time**               | The opposite — booking must be at least N days *after* now.               |
| **Per-channel exposure**    | A rate plan visible on one channel but not another.                       |

Each one is independent; you layer them as the situation needs.

## 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:

1. Open the date range on the rate calendar.
2. Drag-select the cells.
3. Click *Stop-sale*; preview shows the affected cells, channels and existing bookings.
4. 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.

## 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.
* **Lead time 90 days** — used in some cases to push back booking windows for peak season.

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.

## How restrictions stack

When several restrictions apply to the same booking attempt, 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, 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 Adragent 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](/console/pricing-and-availability/rate-plans.md)
* **The inventory side** → [Inventory](/console/pricing-and-availability/inventory.md)
* **Promotions layered on top of unrestricted cells** → [Promotions & discounts](/console/pricing-and-availability/promotions-and-discounts.md)
* **Per-cell change history** → [Cell history](/console/pricing-and-availability/cell-history.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/pricing-and-availability/stop-sale-restrictions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.