# Availability

## What is Availability?

**Availability** is an update method where the Property Management System (PMS) actively sends room inventory counts to the SiteMinder Platform for distribution across all connected channels. This integration ensures that all booking channels receive synchronized availability updates in real-time, preventing overbookings and maintaining accurate inventory control.

{% hint style="warning" %}
**Best Practice**: While availability and restrictions can technically be sent together using the `OTA_HotelAvailNotifRQ` message, we recommend sending them in separate requests for better processing and clarity.
{% endhint %}

## 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>SiteMinder will provide a single global endpoint for all hotels for PMS to send update requests <code>OTA_HotelAvailNotifRQ</code> and receive confirmation responses <code>OTA_HotelAvailNotifRS</code>.</li><li><strong>Test Environment Endpoint:</strong> <a href="https://tpi-pmsx.preprod.siteminderlabs.com/webservices/%7BRequestorID%7D">https://tpi-pmsx.preprod.siteminderlabs.com/webservices/{RequestorID}</a></li></ul></td></tr><tr><td><strong>Authentication</strong></td><td><ul><li>SiteMinder will provide a single username/password for all hotels (PMS Level authentication).</li><li>PMS must include authentication credentials within the <strong>SOAP Security header</strong> of each request <code>OTA_HotelAvailNotifRQ</code>.</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 will 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></ul></td></tr></tbody></table>

## Message Exchange Flow

When your PMS needs to update room availability, it sends updates to SiteMinder using a synchronous SOAP/HTTPS exchange. SiteMinder then distributes these updates to all connected channels in real-time. Each update triggers a simple request-response cycle.

1. **Availability Update (PMS to SiteMinder)**: `OTA_HotelAvailNotifRQ` Delivers availability counts for specific room types and rate plans across defined date ranges.
2. **Confirmation Response (SiteMinder to PMS)**: `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 your PMS to SiteMinder endpoint. It contains the username and password credentials that we provide to the PMS during integration setup.

**Key Requirements:**

* **Validation**: Our 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.

{% hint style="info" %}
The only acceptable value for the **Password @Type** attribute is *<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText>.* Plain text passwords are acceptable as all communication is done over encrypted HTTP (HTTPS).
{% endhint %}

{% tabs %}
{% tab title="Availability 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
			xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP-ENV:mustUnderstand="1">
			<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" Version="1.0" TimeStamp="2024-07-06T15:27:41+00:00" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c">
			<!-- ... 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" Version="1.0" TimeStamp="2024-07-06T15:27:41+00:00" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c">
			<Success/>
		</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 Update**

The `OTA_HotelAvailNotifRQ` message carries availability updates from your PMS to SiteMinder. Each message contains updates for exactly one hotel, with the ability to send multiple date ranges and room/rate combinations in a single request.

The message consists of an AvailStatusMessages container that holds individual AvailStatusMessage elements. Each AvailStatusMessage can update availability counts, for specific date ranges and rooms.

#### **Key Concepts**

**AvailStatusMessages**

* Container for all availability and restriction updates in the request.
* Always contains exactly one hotel's updates (identified by `HotelCode`).
* Can contain multiple `AvailStatusMessage` elements.

**AvailStatusMessage**

* Represents a single update instruction for specific dates.
* Must target room level (`InvTypeCode` only).

**Delta Updates**

* Only send data that has changed since the last update.
* Required for production to avoid system overload.
* Critical for efficient processing and performance.

**Bundling Updates**

* Consolidate consecutive dates with identical values into a single `AvailStatusMessage`.
* Focus each request on one room type.
* Use day-of-week flags to handle weekday/weekend variations within the same date range.

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

* **Availability** is the number of rooms available for sale.
* Set at the room type level (`InvTypeCode`).
* Uses the `@BookingLimit` attribute to specify the count.
* All rate plans under the same room type share the same availability pool.

```xml
<OTA_HotelAvailNotifRQ
	xmlns="http://www.opentravel.org/OTA/2003/05" Version="1.0" TimeStamp="2024-07-06T15:27:41+00:00" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c">
	<POS>
		<Source>
			<RequestorID Type="22" ID="PMSCODE"/>
		</Source>
	</POS>
	<AvailStatusMessages HotelCode="HOTELCODE">
		<AvailStatusMessage BookingLimit="10">
			<StatusApplicationControl Start="2025-03-01" End="2025-03-01" InvTypeCode="SUP"/>
		</AvailStatusMessage>
	</AvailStatusMessages>
</OTA_HotelAvailNotifRQ>
```

{% endtab %}
{% endtabs %}

### Update Multiple Values Examples

{% tabs %}
{% tab title="Availability Update" %}
Here is an example of an `OTA_HotelAvailNotifRQ` that updates only **Availability** for the same room in a single request:

```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">
	<POS>
		<Source>
			<RequestorID Type="22" ID="PMSCODE"/>
		</Source>
	</POS>
	<AvailStatusMessages HotelCode="HOTEL">
		<AvailStatusMessage BookingLimit="10"> <!-- Availability -->
			<StatusApplicationControl Start="2025-03-01" End="2025-03-14" InvTypeCode="SUP"/>
		</AvailStatusMessage>
		<AvailStatusMessage BookingLimit="5"> <!-- Availability -->
			<StatusApplicationControl Start="2025-03-15" End="2025-03-31" InvTypeCode="SUP"/>
		</AvailStatusMessage>
		<!-- Additional AvailStatusMessage elements -->
	</AvailStatusMessages>
</OTA_HotelAvailNotifRQ>
```

{% endtab %}
{% endtabs %}

<table><thead><tr><th width="285">Element / @Attribute</th><th width="139">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>POS / Source / RequestorID</code></td><td></td><td align="center">1</td><td></td></tr><tr><td><code>@Type</code></td><td></td><td align="center">1</td><td>Fixed at <code>22</code> (ESRP)</td></tr><tr><td><code>@ID</code></td><td>String</td><td align="center"></td><td></td></tr><tr><td><code>AvailStatusMessages</code></td><td>Element</td><td align="center">1</td><td>Container for availability and restriction 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..n</td><td>Single availability or restriction status message.</td></tr><tr><td><code>@BookingLimit</code></td><td>Integer ≥ 0</td><td align="center">0..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. <strong>Note:</strong> No overlapping dates allowed.</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">0..1</td><td>Identifies the room type.</td></tr><tr><td><code>@RatePlanCode</code></td><td>String</td><td align="center">0..1</td><td>Identifies the rate plan.</td></tr><tr><td><code>Mon</code>, <code>Tue</code>, <code>Weds</code>, <code>Thur</code>, <code>Fri</code>, <code>Sat</code>, <code>Sun</code></td><td>Boolean</td><td align="center">0..1</td><td><p>The <strong>day-of-week indicators</strong> are used to specify which days a rate update applies to. These indicators accept values of <code>"0"</code> or <code>"1"</code>, where:</p><ul><li><strong><code>"1"</code></strong> indicates the update applies to that day.</li><li><strong><code>"0"</code></strong> indicates the update does not apply to that day.</li></ul></td></tr><tr><td><code>LengthsOfStay</code></td><td>Element</td><td align="center">0..1</td><td>Used for Minimum Stay and Maximum Stay.</td></tr><tr><td><code>LengthOfStay</code></td><td>Element</td><td align="center">1..2</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: <code>SetMinLOS</code></p><p><code>SetMaxLOS</code></p></td></tr><tr><td><code>@Time</code></td><td>Integer > 0</td><td align="center">1</td><td><p>Specifies the number of days related to a stay.</p><p><code>SetMinLOS</code> : Minimum days required for a stay.</p><p><code>SetMaxLOS</code> : Maximum days bookable.</p><p><code>@Time</code> value must be above <strong>0.</strong> To remove<code>MaxLOS</code>), set <code>@Time</code> to <strong>999</strong>.</p></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 rate.</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="2025-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" Version="1.0" TimeStamp="2025-08-01T09:30:47+08:00" EchoToken="echo-abc123">
  <Errors>
    <Error Type="6">PMS is not authorized to access hotel with HotelCode=XXXX</Error>
  </Errors>
</OTA_HotelAvailNotifRS>
```

{% endtab %}

{% tab title="Error" %}

```xml
<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" Version="1.0" TimeStamp="2025-08-01T09:30:47+08:00" EchoToken="echo-abc123">
  <Errors>
    <Error Type="10">Status should be "Close" or "Open"</Error>
  </Errors>
</OTA_HotelAvailNotifRS>
```

{% endtab %}

{% tab title="Error" %}

```xml
<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" Version="1.0" TimeStamp="2025-08-01T09:30:47+08:00" EchoToken="echo-abc123">
  <Errors>
    <Error Type="10">Time should be a number between 1 and 9999</Error>
  </Errors>
</OTA_HotelAvailNotifRS>
```

{% endtab %}
{% endtabs %}

<table><thead><tr><th width="259">Element / @Attribute</th><th width="108">Type</th><th width="70" 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="https://developer.siteminder.com/sm-apis/additional-resources/reference-tables/error-warning-types-ewt">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>Can I send availability and restrictions updates in the same message?</summary>

Yes, but send them separately for better processing.

The `OTA_HotelAvailNotifRQ` message supports both, but separate requests provide clearer error handling and easier troubleshooting.

</details>

<details>

<summary>How often should I send availability and restrictions updates?</summary>

Send delta updates in real-time as changes occur in your PMS (within 2 minutes).

Only send data that has changed - do not resend unchanged availability or restrictions.

</details>

<details>

<summary>Can I send full flushes daily to ensure complete synchronization?</summary>

No. Full flushes are only for initial setup or when requested by SiteMinder support.

Delta updates (changes only) are required in production. Frequent full flushes cause system overload and must be avoided.

</details>

<details>

<summary>When availability or restrictions change for a date, do I need to include all data in the message?</summary>

No. Send only what changed.

If availability changed, send only the new availability value. If a restriction changed, send only that restriction. Do not include unchanged data in your message.

Send changes only for the specific room type and rate plan that changed - do not include other room types or rate plans.

</details>

<details>

<summary>What happens when availability and restrictions conflict?</summary>

Restrictions take priority over availability.

**Priority order:**

1. **Stop Sell** - Overrides everything; if closed, room rate cannot be booked
2. **CTA/CTD** - Controls arrival/departure when Stop Sell is open
3. **Availability** - Room count when restrictions allow booking

**Both must allow booking:**

* Stop Sell = Close, Availability = 10 → Cannot book (restrictions block)
* Stop Sell = Open, Availability = 0 → Cannot book (no inventory)
* Stop Sell = Open, Availability = 10 → Can book ✓

Update availability and restrictions independently - stored availability activates when restrictions open.

</details>

<details>

<summary>Can I set different restrictions for different rate plans on the same room type?</summary>

Yes. Restrictions are set at the room rate level, while availability is set at the room type level.

**Availability (Room Level):**

* Applied to the entire room type (InvTypeCode only)
* All rate plans share the same availability pool
* Example: 10 Double Rooms available for ALL rate plans

**Restrictions (Room Rate Level):**

* Applied to specific room/rate combinations (InvTypeCode + RatePlanCode)
* Each rate plan can have independent restrictions
* Example: Double Room - BAR (Stop Sell = Close), Double Room - B\&B (Stop Sell = Open)

</details>

<details>

<summary>Does SiteMinder automatically reduce availability for all reservation types?</summary>

No. Only new bookings trigger automatic reduction for quick channel updates.

Your PMS must send availability updates via `OTA_HotelAvailNotifRQ` for all reservation types (Book, Modify, Cancel) - you are the master source of availability data.

</details>

<details>

<summary>How many dates in advance does SiteMinder support?</summary>

Up to 750 days in the future.

Properties can configure their inventory distribution window between 400-750 days based on their preferences.

</details>

<details>

<summary>Do you support Minimum/Maximum Stay Through?</summary>

No. pmsXchange only supports standard MinLOS/MaxLOS (applied on check-in date).

Stay Through restrictions (applied when any part of the reservation touches a date) are not currently supported.

</details>

<details>

<summary>Do you support Patterned Length of Stay (e.g., only 7, 14, 21, or 28 days)?</summary>

Not directly, but use multiple rate plans with different MinLOS values.

Example: Create "Weekly" (MinLOS = 7), "Bi-Weekly" (MinLOS = 14), and "Monthly" (MinLOS = 28) rate plans for the same room type, each with appropriate pricing.

</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/pmsxchange-api/reference/availability.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.