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:

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

<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.