---
title: 'Set minimum stays'
url: 'https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-minimum-stays'
markdown: 'https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-minimum-stays.md'
date: '2026-04-09'
description: 'The supplier sends this message to set the value of “minimum stay” parameter: with this method you can set the minimum number of nights that has to be booked for a specific combination (period, contract and, if you want, also room type). The query type (type) is set to setminimumstay. PAY ATTENTION…'
taxonomy:
  category:
    - docs
---

# Set minimum stays

[](#)  [ Channel Manager ](https://documentation.netstorming.net/channel-manager)     [ Channel Manager Protocol ](https://documentation.netstorming.net/channel-manager/channel-manager-protocol)      Set minimum stays    

The supplier sends this message to set the value of “minimum stay” parameter: with this method you can set the minimum number of nights that has to be booked for a specific combination (period, contract and, if you want, also room type). The query type (**type**) is set to **setminimumstay**.

**PAY ATTENTION**: A period of allotment must be already entered in order to process the request. The period must exist, it doesn’t matter with which values.

**PAY ATTENTION**: it is recommended to use this instruction AFTER the allotments setting in order to avoid overwritings.

Setting **nights = 1** you can delete a minimum stay > 1 which has been previous inserted. The value 1 means that, for a specific period, there isn't any minimum stay set.

Below you can see the fields you can find in the message body and their meanings.

##### Request

- **startdate**

    effective date of the period with minimum stay
- **enddate**

    end date of the period with minimum stay
- **nights**

    number of nights
- **roomtype**

    this is an optional field, that you can use if you want to set a specific minimum stay only for a specific room type (and not for all the room types bound to the contract). Parameter which identifies the room type:
- - **SGL single room**
- - **TSU twin for sole use room**

        If present, it has to be specified. The TSU doesn't inherit the minimum stay of the TWN.
- - **TWN twin room**
- - **DBL double room**
- - **TRP triple room**
- - **QUD quadruple room**
- - **STR big accommodations**
- **checkindays**

    this field has to be set to 0,1,2 etc; the values refer to the days of the week ('MON':0, 'TUE':1, 'WED':2, 'THU':3, 'FRI':4, 'SAT':5, 'SUN':6).
- **forced\_checkin**

    (optional) Boolean (Y/N) value:

    - Y: if True, stays are forced to start in one of the days defined in the minimum stay's checkindays otherwise there won't be any availability
    - N: if False, when a stay does not start in one of the days defined in the minimum stay's checkindays, the minimum stay rule won't be applied
- **forced**

    (optional) Boolean (Y/N) value:

    - Y: if True, at least N nights must be booked inside the min stay interval
    - N: if False, N stay nights are sufficient even if partially outside the min stay interval (default if missing)
- **multiple**

    (optional) Boolean (Y/N) value:

    - Y: if True, nights booked must have a value multiple of nights value (i.e. 7 nights multiple means 14 nights is ok but 13 or 15 are not)
    - N: if False, nights will be respected as is (default if missing)

Let’s see an example of message the client could send.

```
<?xml version="1.0" encoding="UTF-8"?>
<envelope>
    <header>
        <actor>...</actor>
        <user>...</user>
        <password>...</password>
        <version>1.0.0</version>
        <timestamp>20210808162849</timestamp>
        <transaction>52791</transaction>
    </header>
    <query type="setminimumstay" product="hotel" agrement="1299">
    <!-- new template with night = 3 -->
         <date>
            <startdate>2022-06-10</startdate>
            <enddate>2022-06-25</enddate>
<!-- not mandatory -->
          <roomtype>DBL</roomtype>
            <nights>3</nights>          
            <checkindays>
                <checkinday>0</checkinday>
                <checkinday>1</checkinday>
            </checkindays>
            <forced_checkin>Y</forced_checkin>
            <forced>Y</forced>
            <multiple>Y</multiple>
        </date>     
    </query>
</envelope>
```

##### Response

The reply message contains, within tag **response**, the string "OK" or in case of error the string "error code XX (description)", where XX represents an error code (error code list)

## Overlap rules for minimum stay records

Two minimum stay records for the same contract are considered **overlapping** when **both** of the following conditions hold:

1. Their date ranges overlap — i.e. `startdate₁ ≤ enddate₂` and `enddate₁ ≥ startdate₂`.
2. Their `checkindays` values are compatible — see the table below.

### checkindays compatibility

| Record A checkindays | Record B checkindays | Compatible (may overlap)? |
|---|---|---|
| *(empty — all days)* | *(empty — all days)* | **Yes** |
| Specific days (e.g. `0,1`) | Specific days sharing at least one digit | **Yes** |
| Specific days (e.g. `0,1`) | Specific days with no digit in common (e.g. `2,3`) | No |
| *(empty — all days)* | Any specific days | **No** — treated as orthogonal |

> The last row is intentional: an "all days" record and a specific-day record can coexist in the same date range without conflicting. They apply to different selection contexts.

### Rules inside a single request

A single `setminimumstay` query may contain multiple `<date>` blocks. Two blocks in the same request are rejected with an error if **all three** of the following are true simultaneously:

- They cover at least one calendar day in common.
- Their `checkindays` values are compatible (see table above).
- They specify **different** values for `nights` or for any room type field (`SGL`, `DBL`, …).

If two blocks cover the same day with compatible `checkindays` but identical values, they are silently merged.

**Invalid example** — Monday (`0`) appears in both blocks with different `nights`:

```xml
<query type="setminimumstay" product="hotel" agrement="1299">
  <date>
    <startdate>2026-06-01</startdate>
    <enddate>2026-06-30</enddate>
    <nights>3</nights>
    <checkindays><checkinday>0</checkinday><checkinday>1</checkinday></checkindays>
  </date>
  <date>
    <startdate>2026-06-01</startdate>
    <enddate>2026-06-30</enddate>
    <nights>5</nights>
    <checkindays><checkinday>0</checkinday><checkinday>2</checkinday></checkindays>
    <!-- ERROR: day 0 (Monday) already claimed above with nights=3 -->
  </date>
</query>
```

**Valid example** — days are disjoint, so the blocks are orthogonal:

```xml
<query type="setminimumstay" product="hotel" agrement="1299">
  <date>
    <startdate>2026-06-01</startdate>
    <enddate>2026-06-30</enddate>
    <nights>3</nights>
    <checkindays><checkinday>0</checkinday><checkinday>1</checkinday></checkindays>
    <!-- Mon, Tue -->
  </date>
  <date>
    <startdate>2026-06-01</startdate>
    <enddate>2026-06-30</enddate>
    <nights>5</nights>
    <checkindays><checkinday>2</checkinday><checkinday>3</checkinday></checkindays>
    <!-- Wed, Thu — no overlap with the block above -->
  </date>
</query>
```

### How existing records are replaced

When the request is accepted, the system:

1. **Deletes** all existing records for the contract whose date range overlaps the requested period.
2. **Re-inserts** any portion of a deleted record that fell **outside** the requested period (split/preserve behaviour).
3. **Inserts** the new records.

This means you only need to worry about internal consistency within your request. Records outside the requested period are never touched.

**Example — partial overlap with an existing record**

Existing state before the call:

| startdate | enddate | nights | checkindays |
|---|---|---|---|
| 2026-06-01 | 2026-06-30 | 3 | *(all days)* |

Request sent: `nights=5` for `2026-06-10 → 2026-06-20`, empty `checkindays`.

Resulting state after the call:

| startdate | enddate | nights | checkindays |
|---|---|---|---|
| 2026-06-01 | 2026-06-09 | 3 | *(all days)* |
| 2026-06-10 | 2026-06-20 | 5 | *(all days)* |
| 2026-06-21 | 2026-06-30 | 3 | *(all days)* |

### Resetting a minimum stay

Send `nights=1` for the period and `checkindays` you want to reset. The value `1` means *no restriction*, so any previously set minimum stay greater than 1 for that combination is effectively removed.

 [ ](https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-closures-for-checkin) [](https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-maximum-stays)

---

## Navigation

- Parent: [Channel Manager Protocol](https://documentation.netstorming.net/channel-manager/channel-manager-protocol.md)
- Previous: [Set closures for checkin (deprecated)](https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-closures-for-checkin.md)
- Next: [Set maximum stays](https://documentation.netstorming.net/channel-manager/channel-manager-protocol/set-maximum-stays.md)