# Availability and Restrictions

## What is Availability and Restrictions?

**Availability and Restrictions** is an update method where the SiteMinder Platform actively sends room inventory counts and booking restrictions to the booking channel. This integration ensures that the booking channel receive synchronized availability and restriction updates in real-time, preventing overbookings and maintaining accurate inventory control.

The API handles two primary data types:

* **Availability Updates**: Real-time room inventory counts that define how many rooms are available for sale on specific dates.
* **Restriction Updates**: Booking rules and limitations including stop sells, closed to arrival/departure, and minimum/maximum length of stay requirements.

## Integration Requirements

Understand the essential requirements for API integration, including connectivity, authentication, message formats, and security protocols.

<table data-header-hidden><thead><tr><th width="199.954833984375">Category</th><th>Requirement</th></tr></thead><tbody><tr><td><strong>Web Service Endpoint</strong></td><td><ul><li>The booking channel will provide a single global endpoint for all hotels for SiteMinder to push <code>OTA_HotelAvailNotifRQ</code> messages and receive <code>OTA_HotelAvailNotifRS</code> responses indicating success or failure.</li><li>The endpoint must use a registered domain name.</li><li>Direct IP addresses are not supported and cannot be used as endpoints.</li></ul></td></tr><tr><td><strong>Authentication</strong></td><td><ul><li>The booking channel will provide a single username/password for all hotels.</li><li>SiteMinder will include authentication credentials within the <strong>SOAP Security header</strong> of each <code>OTA_HotelAvailNotifRQ</code>.</li><li>Credentials must follow a strong password policy: minimum of 12 characters, including a mix of uppercase and lowercase letters, numbers, and at least one special character (e.g., <code>!</code> <code>@</code> <code>#</code> <code>?</code> <code>]</code>).</li><li>Do not use <code>&#x3C;</code> <code>></code> <code>&#x26;</code> <code>"</code> <code>'</code> as they can cause issues with the Web Service.</li></ul></td></tr><tr><td><strong>Message Structure</strong></td><td><ul><li>All messages must adhere to the SOAP message format.</li><li>OTA message must be encapsulated within the SOAP Body.</li><li>Requests must include a SOAP Security Header for authentication.</li><li>Responses must be returned in a SOAP envelope with empty SOAP Header.</li></ul></td></tr><tr><td><strong>Content-Type</strong></td><td><code>text/xml; charset=utf-8</code></td></tr><tr><td><strong>Version</strong></td><td><code>SOAP 1.1</code></td></tr><tr><td><strong>Protocol &#x26; Security</strong></td><td><ul><li>All communication must occur over <strong>HTTPS</strong> using <strong>TLS 1.2 or higher</strong>.</li><li>Non-secure (HTTP) connections are <strong>not permitted</strong>.</li><li>Communication is synchronous request/response pairs.</li><li>Each message is atomic - processed entirely or not at all.</li><li>SiteMinder sends requests over <strong>port 443</strong>.</li></ul></td></tr><tr><td><strong>IP Whitelisting</strong></td><td><p><strong>Pre-Production IP addresses:</strong><br></p><p><code>52.13.134.140</code></p><p><code>34.213.128.113</code></p><p><code>35.164.250.223</code><br><br><strong>Production IP addresses will be provided during go-live.</strong></p></td></tr></tbody></table>

## Message Exchange Flow

When SiteMinder needs to update room availability or booking restrictions, it sends updates to your booking channels using a synchronous SOAP/HTTPS exchange. Each update triggers a simple request-response cycle.

1. **Availability and Restrictions Update (SiteMinder to booking channel)**: `OTA_HotelAvailNotifRQ`\
   Delivers availability counts and/or booking restrictions (stop sells, CTA, CTD, min/max stay) for specific room types and rate plans across defined date ranges.
2. **Confirmation Response (booking channel to SiteMinder)**: `OTA_HotelAvailNotifRS`\
   Confirms successful receipt and processing or reports validation errors.

## Security Header

The Security Header is a mandatory SOAP header that authenticates every request from SiteMinder to your booking channel endpoint. It contains the username and password credentials that you provide to the SiteMinder during integration setup.

**Key Requirements:**

* **Validation**: Your endpoint will validate these credentials on every request.
* **Scope**: One set of credentials is used for all properties in your integration.
* **Security**: Credentials are transmitted as plain text within the HTTPS encrypted channel.
* **Response**: Invalid credentials will return a SOAP fault with appropriate error code.

{% tabs %}
{% tab title="Availability and Restrictions Update" %}
Requests must include a SOAP Security Header for authentication.

```xml
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
	<SOAP-ENV:Header>
		<wsse:Security SOAP-ENV:mustUnderstand="1"
			xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
			<wsse:UsernameToken>
				<wsse:Username>USERNAME</wsse:Username>
				<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PASSWORD</wsse:Password>
			</wsse:UsernameToken>
		</wsse:Security>
	</SOAP-ENV:Header>
	<SOAP-ENV:Body>
		<OTA_HotelAvailNotifRQ
			xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
			<!-- ... other elements and attributes have been omitted for brevity ... -->
		</OTA_HotelAvailNotifRQ>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
```

{% endtab %}

{% tab title="Confirmation Response" %}
Responses must be returned in a SOAP envelope with an empty SOAP Header.

```xml
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
	<SOAP-ENV:Header/>
	<SOAP-ENV:Body>
		<OTA_HotelAvailNotifRS
			xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
			<Success/>
			<!-- ... other elements and attributes have been omitted for brevity ... -->
		</OTA_HotelAvailNotifRS>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
```

{% endtab %}
{% endtabs %}

## Multiplicity

In the SOAP Specification tables below **M** refers to the number of instances or occurrences of an element or attribute that are allowed or required in a given context. It defines how many times a particular component (element or attribute) can appear within a specific structure.

<table><thead><tr><th width="94">M</th><th>Definition</th></tr></thead><tbody><tr><td><strong>1</strong></td><td>The element or attribute must be present exactly once.</td></tr><tr><td><strong>0..1</strong></td><td>The element or attribute is optional; it can be present zero or one time.</td></tr><tr><td><strong>0..n</strong></td><td>The element or attribute can be present zero or more times, with no upper limit (where <strong>n</strong> represents an infinite number of occurrences).</td></tr><tr><td><strong>1..n</strong></td><td>The element or attribute must be present at least once and can be present any number of times, with no upper limit.</td></tr><tr><td><strong>n..m</strong></td><td>Specific range, the element or attribute must be present at least <strong>n</strong> times and no more than <strong>m</strong> times (where <strong>n</strong> and <strong>m</strong> are specific numbers).</td></tr></tbody></table>

## **1. Availability and Restrictions Update**

Each Availability and Restrictions message contains a single `AvailStatusMessages` element which indicates the hotel to update using the `AvailStatusMessages` / `HotelCode` attribute. The `AvailStatusMessages` / `AvailStatusMessage` elements will contain the updates to process over a date range. There can be several `AvailStatusMessage` updates per request; however, each request will be limited to one hotel and one room type.

#### **Key Concepts**

**Response Behaviour for Stop Sells:** If the partner's system does not support stop sells, it is required that the system interpret a RestrictionStatus of "Close" as equivalent to zero availability. This ensures consistency in how availability is communicated between SiteMinder and the booking channel, preventing errors when managing inventory. This behaviour is allowed only if the booking channel supports one rate plan per room type.

**Minimum Stay and Maximum Stay:** Can be defined as either:

* **"Stay on Arrival"** (based on the arrival date): `SetMinLOS` or `SetMaxLOS`
* **"Stay Through"** (covering the entire stay): `SetForwardMinStay` or `SetForwardMaxStay`

The Min/Max Stay Through option is managed at the property level. Once certified, each property can choose their preferred setting.

{% hint style="success" %}
To enable Min/Max Stay Through, the booking channel must also support Min/Max Stay On Arrival.
{% endhint %}

{% tabs %}
{% tab title="Stay on Arrival" %}

```xml
<OTA_HotelAvailNotifRQ
	xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
	<AvailStatusMessages HotelCode="HOTELCODE">
		<AvailStatusMessage BookingLimit="10"> <!-- Availability -->
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Status="Open"/> <!-- Stop Sell -->
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<LengthsOfStay>
				<LengthOfStay MinMaxMessageType="SetMinLOS" Time="1"/> <!-- Min Length of Stay -->
				<LengthOfStay MinMaxMessageType="SetMaxLOS" Time="3"/> <!-- Max Length of Stay -->
			</LengthsOfStay>
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Restriction="Arrival" Status="Open"/> <!-- Close to Arrival (CTA) -->
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Restriction="Departure" Status="Open"/> <!-- Close to Departure (CTD) -->
		</AvailStatusMessage>
		<!-- Additional AvailStatusMessage elements -->
	</AvailStatusMessages>
</OTA_HotelAvailNotifRQ>
```

{% endtab %}

{% tab title="Stay Through" %}

```xml
<OTA_HotelAvailNotifRQ
	xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
	<AvailStatusMessages HotelCode="HOTELCODE">
		<AvailStatusMessage BookingLimit="10"> <!-- Availability -->
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Status="Open"/> <!-- Stop Sell -->
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<LengthsOfStay>
				<LengthOfStay MinMaxMessageType="SetForwardMinStay" Time="1"/> <!-- Min Length of Stay -->
				<LengthOfStay MinMaxMessageType="SetForwardMaxStay" Time="3"/> <!-- Max Length of Stay -->
			</LengthsOfStay>
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Restriction="Arrival" Status="Open"/> <!-- Close to Arrival (CTA) -->
		</AvailStatusMessage>
		<AvailStatusMessage>
			<StatusApplicationControl End="2024-10-05" InvTypeCode="SGL" RatePlanCode="BAR" Start="2024-10-05"/>
			<RestrictionStatus Restriction="Departure" Status="Open"/> <!-- Close to Departure (CTD) -->
		</AvailStatusMessage>
		<!-- Additional AvailStatusMessage elements -->
	</AvailStatusMessages>
</OTA_HotelAvailNotifRQ>
```

{% endtab %}
{% endtabs %}

<table><thead><tr><th width="285">Element / @Attribute</th><th width="108">Type</th><th width="60" align="center">M</th><th>Description</th></tr></thead><tbody><tr><td><code>OTA_HotelAvailNotifRQ</code></td><td>Element</td><td align="center">1</td><td>Root element for the request.</td></tr><tr><td><code>@xmlns</code></td><td>String</td><td align="center">1</td><td>Defines the XML namespace for the request. Will be set to <code>http://www.opentravel.org/OTA/2003/05</code></td></tr><tr><td><code>@EchoToken</code></td><td>String</td><td align="center">1</td><td>Unique identifier for the request, used to match requests and responses.</td></tr><tr><td><code>@TimeStamp</code></td><td>DateTime</td><td align="center">1</td><td>Time when the request was generated.</td></tr><tr><td><code>@Version</code></td><td>String</td><td align="center">1</td><td>Specifies the API version. Will be set to <code>1.0</code>.</td></tr><tr><td><code>AvailStatusMessages</code></td><td>Element</td><td align="center">1</td><td>Container for availability status messages.</td></tr><tr><td><code>@HotelCode</code></td><td>String</td><td align="center">1</td><td>Identifier for the hotel.</td></tr><tr><td><code>AvailStatusMessage</code></td><td>Element</td><td align="center">1</td><td>Single availability status message.</td></tr><tr><td><code>@BookingLimit</code></td><td>Integer</td><td align="center">1</td><td>Sets the number of rooms available for sale.</td></tr><tr><td><code>StatusApplicationControl</code></td><td>Element</td><td align="center">1</td><td>Contains date and room identification information.</td></tr><tr><td><code>@Start</code></td><td>Date</td><td align="center">1</td><td>The start date for which the update is being set. This date is inclusive.</td></tr><tr><td><code>@End</code></td><td>Date</td><td align="center">1</td><td>The end date for which the update is being set. This date is inclusive.</td></tr><tr><td><code>@InvTypeCode</code></td><td>String</td><td align="center">1</td><td>Identifies the room.</td></tr><tr><td><code>@RatePlanCode</code></td><td>String</td><td align="center">1</td><td>Identifies the rate.</td></tr><tr><td><code>LengthsOfStay</code></td><td>Element</td><td align="center">0..2</td><td>Used for Minimum Stay and Maximum Stay.</td></tr><tr><td><code>LengthOfStay</code></td><td>Element</td><td align="center">1</td><td>Single length of stay information.</td></tr><tr><td><code>@MinMaxMessageType</code></td><td>String</td><td align="center">1</td><td><p>Can be one of the following:</p><p><code>SetMinLOS</code></p><p><code>SetMaxLOS</code></p><p><code>SetForwardMinStay</code></p><p><code>SetForwardMaxStay</code></p></td></tr><tr><td><code>@Time</code></td><td>Integer</td><td align="center">0..1</td><td>Specifies the number of days related to a stay. Valid range: 1 to 9999.<br><br><strong>Minimum Stay:</strong> Always included with minimum value of 1.<br><br><strong>Maximum Stay:</strong> When <strong>included</strong>: Set or update the maximum stay value. When <strong>excluded</strong>: Remove/clear any existing maximum stay restriction.</td></tr><tr><td><code>RestrictionStatus</code></td><td>Element</td><td align="center">0..1</td><td>Used to restrict the room for Stop Sell, Closed to Arrivals, and Closed to Departure.</td></tr><tr><td><code>@Status</code></td><td>String</td><td align="center">1</td><td><p>Values:</p><p><code>Open</code> (opens room for sale)</p><p><code>Close</code> (closes room for sale)</p></td></tr><tr><td><code>@Restriction</code></td><td>String</td><td align="center">0..1</td><td><p>Values:</p><p><code>Arrival</code> (closes to arrival)</p><p><code>Departure</code> (closes to departure)</p><p>If no type is specified, assume a full close or open for the room date.</p></td></tr></tbody></table>

## 2. **Confirmation Response**

{% tabs %}
{% tab title="Success" %}

```xml
<OTA_HotelAvailNotifRS
	xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
	<Success/>
</OTA_HotelAvailNotifRS>
```

{% endtab %}

{% tab title="Error" %}

```xml
<OTA_HotelAvailNotifRS
	xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41+00:00" Version="1.0">
	<Errors>
		<Error Type="6" Code="392">Hotel not found for HotelCode=HOTELCODE</Error>
	</Errors>
</OTA_HotelAvailNotifRS>
```

{% endtab %}
{% endtabs %}

<table><thead><tr><th width="259">Element / @Attribute</th><th width="108">Type</th><th width="58" align="center">M</th><th>Description</th></tr></thead><tbody><tr><td><code>OTA_HotelAvailNotifRS</code></td><td>Element</td><td align="center">1</td><td>Root element for the response.</td></tr><tr><td><code>@xmlns</code></td><td>String</td><td align="center">1</td><td>Defines the XML namespace for the request. Will be set to <code>http://www.opentravel.org/OTA/2003/05</code></td></tr><tr><td><code>@EchoToken</code></td><td>String</td><td align="center">1</td><td>Unique identifier for the request, used to match requests and responses.</td></tr><tr><td><code>@TimeStamp</code></td><td>DateTime</td><td align="center">1</td><td>Time when the response was generated.</td></tr><tr><td><code>@Version</code></td><td>String</td><td align="center">1</td><td>Specifies the API version. Must be set to <code>1.0</code>.</td></tr><tr><td><code>Success</code></td><td>Element</td><td align="center">0..1</td><td>Indicates successful processing of the request.</td></tr><tr><td><code>Errors</code></td><td>Element</td><td align="center">0..1</td><td>Indicates an error occurred during the processing of the request.</td></tr><tr><td><code>Error</code></td><td>Element</td><td align="center">1..n</td><td>Single error information containing free text.</td></tr><tr><td><code>@Type</code></td><td>Integer</td><td align="center">1</td><td>Type of error. Refer to <a href="/pages/eTWh81Gq6djsnm0unSR4">Error Warning Types (EWT)</a>.</td></tr><tr><td><code>@Code</code></td><td>Integer</td><td align="center">0..1</td><td>Code representing the error. Refer to <a href="/pages/4gDxPCSFeyblWHTelhiH">Error Codes (ERR)</a>.</td></tr></tbody></table>

## Common Questions

<details>

<summary>What updates can be sent in a single message?</summary>

Each `OTA_HotelAvailNotifRQ` message is limited to:

* **One hotel** (`HotelCode`)
* **One room type** (`InvTypeCode`)
* **Multiple rate plans** under that room type
* **Multiple date ranges**

Within these constraints, a single message can contain multiple `AvailStatusMessage` elements updating:

* Availability counts (`BookingLimit`)
* Stop Sell status
* Minimum/Maximum Length of Stay
* Close to Arrival (CTA)
* Close to Departure (CTD)

**Example:** You might receive availability, stop sell, and min stay updates for the same room type across different date ranges in one message.

</details>

<details>

<summary>How often will I receive availability and restriction updates?</summary>

**Update Frequency:**

* New update rounds sent every **2 minutes**
* Only changed values for specific room/rate/date combinations are sent
* When a change is triggered, **all** availability and restriction values for that combination are included

**Update Volume:**

* Maximum payload: **210 days** (30 date elements × 7-day spans)
* Response speed affects update frequency - faster responses enable more frequent updates
* First-time connections receive full inventory data for the configured update period

**Important:** Your endpoint must respond within the 20-second timeout, with 1-2 seconds being optimal.

</details>

<details>

<summary>What's the difference between <strong>Room Type level</strong> and Rate Plan level availability?</summary>

**Room Type Level (default):**

* Availability is **shared across all rate plans** for a room type
* Same inventory count applies to all rates (BAR, Non-Refundable, etc.)
* When one rate plan is booked, availability for **all rate plans** under that room type is reduced
* Your system uses `InvTypeCode` as the primary identifier

**Rate Plan Level:**

* **Separate availability** per rate plan under the same room type
* Each rate (BAR, Non-Refundable, etc.) has its own inventory count
* Booking one rate plan only affects that specific rate's availability
* Hotels must configure this setting in SiteMinder Platform
* Your system must use both `InvTypeCode` and `RatePlanCode` to track inventory

**Implementation:** If you only support Room Type level, use `InvTypeCode` and disregard `RatePlanCode` values. If you support Rate Plan level, track inventory separately using the combination of `InvTypeCode` + `RatePlanCode`.

</details>

<details>

<summary>Is there a mechanism to prevent hotels from entering excessively large availability numbers?</summary>

No, SiteConnect does not validate availability amounts. It is the **hotel's responsibility** to enter correct inventory counts.

**Your system must:**

* Accept any positive integer value for `BookingLimit`
* Not impose arbitrary limits on availability counts
* Process updates as received from SiteMinder

**Why no validation?** Some properties have very large inventories (e.g., major hotels, apartment complexes), and SiteMinder cannot determine what constitutes a "reasonable" number for each property.

</details>

<details>

<summary>How should I handle stop sells if my system doesn't support them as a separate feature?</summary>

If your booking channel does not support stop sells as a distinct feature, you **must interpret** `RestrictionStatus @Status="Close"` (without `@Restriction` attribute) as **equivalent to zero availability**.

**Implementation:**

* When you receive `<RestrictionStatus Status="Close"/>`, set availability to 0
* When you receive `<RestrictionStatus Status="Open"/>`, restore previous availability or await new availability update

**Important limitation:** This behavior is **only allowed** if your booking channel supports **one rate plan per room type**. If you support multiple rate plans per room type, you must implement proper stop sell functionality.

**Why?** This ensures consistent inventory management and prevents overbookings when hotels close rooms for sale.

</details>

<details>

<summary>What's the difference between Stay on Arrival and Stay Through?</summary>

**Stay on Arrival (SetMinLOS / SetMaxLOS):**

* Restriction applies **based on the arrival date**
* Guest must stay minimum/maximum nights **starting from** their check-in date
* Example: Min Stay = 3 on Friday means guests arriving Friday must stay at least 3 nights

**Stay Through (SetForwardMinStay / SetForwardMaxStay):**

* Restriction applies **to the entire length of stay**
* Guest must stay minimum/maximum nights **covering specific dates**
* Example: Min Stay Through = 3 for Friday-Sunday means any stay covering those dates must be at least 3 nights

**Configuration:**

* Hotels choose their preferred method in SiteMinder Platform
* Your channel must support **both** Stay on Arrival **and** Stay Through to enable the Through option
* If you only support one method, implement Stay on Arrival

**Message Type:** SiteMinder indicates which method is used via the `MinMaxMessageType` attribute.

</details>

<details>

<summary>What happens if I don't support certain restriction types?</summary>

You should implement **all mandatory restriction types**, but if you cannot support optional restrictions:

1. Inform SiteMinder Partner Integrations team during certification to remove those restrictions from your configuration
2. In the meantime, return a **Success** response (do not return errors for unsupported features)
3. Simply ignore those specific `AvailStatusMessage` elements
4. Process other supported updates in the same message

**Important:** Do not fail the entire message if you don't support one restriction type. Process what you can support.

</details>

<details>

<summary>What are the date range limitations for updates?</summary>

**Per Message:**

* Maximum payload: **210 days** of data
* Structured as up to 30 date elements with maximum 7-day spans each
* `Start` and `End` dates are **inclusive**

**Update Period:**

* SiteConnect can send updates up to **750 days** in advance
* Specific update period configured during channel setup (typically 365-750 days)
* New date added daily to maintain rolling window

**Date Format:**

* ISO 8601 date format: `YYYY-MM-DD`
* Dates use hotel's local timezone as configured in SiteMinder
* Example: `Start="2024-10-05"` `End="2024-10-12"`

**Bundling:** Dates with identical values are bundled into ranges. Different values are sent in separate `AvailStatusMessage` elements.

</details>

<details>

<summary>Why can't I reset the MinStay field back to blank in SiteMinder Platform?</summary>

This is **expected API and platform behaviour**, not a limitation:

**Current Behaviour:**

* Once MinStay is set, it cannot be reverted to "no restriction"
* Minimum value is **1 night**
* To effectively remove the restriction, set it to 1

**API Representation:**

* SiteMinder will send `<LengthOfStay MinMaxMessageType="SetMinLOS" Time="1"/>`
* This represents the "lowest" restriction (1-night minimum)
* No message is sent to "clear" the restriction

**Why?** In OTA standards and most channel systems, a minimum stay of 1 night is functionally equivalent to having no minimum stay restriction, since 1 night is the natural minimum for any booking.

**Workaround:** If your channel needs to distinguish between "1 night minimum" and "no restriction," treat `Time="1"` as "no restriction" in your system.

</details>

<details>

<summary>How do I handle MaxStay updates without a Time attribute?</summary>

When you receive a `LengthOfStay` element for Maximum Stay **without** a `Time` attribute, this means the Maximum Stay restriction has been **removed** in SiteMinder.

**With Time attribute:** Set or update the maximum stay value `<LengthOfStay MinMaxMessageType="SetMaxLOS" Time="3"/>` → Set max stay to 3 nights

**Without Time attribute:** Remove/clear any existing maximum stay restriction `<LengthOfStay MinMaxMessageType="SetMaxLOS"/>` → Clear max stay restriction

**Why this happens:** Hotels can remove Maximum Stay restrictions in SiteMinder Platform. When they do, SiteMinder sends the update without the `Time` attribute to instruct your channel to clear the restriction.

**Important:** This behaviour applies to **Maximum Stay only** (both `SetMaxLOS` and `SetForwardMaxStay`). Minimum Stay will always include a `Time` attribute with a minimum value of 1.

</details>

{% hint style="success" icon="sparkles" %}

## Still have questions?

Use the <i class="fa-gitbook-assistant">:gitbook-assistant:</i> **Ask** button at the top of the page to chat with our AI assistant — it can help you navigate the guide, understand requirements, and troubleshoot issues.

If you need more support, visit [Integration Support](/integration-support/integration-support.md).
{% endhint %}


---

# 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://developer.siteminder.com/siteconnect-api/reference/availability-and-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.