Help CentrePartner ContactsTest Extranet LoginBecome a SiteMinder Partner

Availability and Restrictions

Sync room inventory and booking restrictions from your PMS to SiteMinder for channel distribution.

What is Availability and Restrictions

Availability and Restrictions is an update method where the Property Management System (PMS) actively sends room inventory counts and booking restrictions to the SiteMinder Platform for distribution across all connected channels. This integration ensures that all booking channels 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.

Web Service Endpoint

Authentication

  • SiteMinder will provide a single username/password for all hotels (PMS Level authentication).

  • PMS must include authentication credentials within the SOAP Security header of each request OTA_HotelAvailNotifRQ.

Message Structure

  • All messages must adhere to the SOAP message format.

  • OTA message must be encapsulated within the SOAP Body.

  • Requests must include a SOAP Security Header for authentication.

  • Responses will be returned in a SOAP envelope with empty SOAP Header.

Content-Type

text/xml; charset=utf-8

Version

SOAP 1.1

Protocol & Security

  • All communication must occur over HTTPS using TLS 1.2 or higher.

  • Non-secure (HTTP) connections are not permitted.

  • Communication is synchronous request/response pairs.

  • Each message is atomic - processed entirely or not at all.

Message Exchange Flow

When your PMS needs to update room availability or booking restrictions, 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 and Restrictions Update (PMS to SiteMinder): 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 (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 reservation 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.

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

Requests must include a SOAP Security Header for authentication.

<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">VKcYa3ShbPkp2AqgFcTsjK</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>

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.

M
Definition

1

The element or attribute must be present exactly once.

0..1

The element or attribute is optional; it can be present zero or one time.

0..n

The element or attribute can be present zero or more times, with no upper limit (where n represents an infinite number of occurrences).

1..n

The element or attribute must be present at least once and can be present any number of times, with no upper limit.

n..m

Specific range, the element or attribute must be present at least n times and no more than m times (where n and m are specific numbers).

1. Availability and Restrictions Update

The OTA_HotelAvailNotifRQ message carries availability and restriction 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, booking restrictions, or both for specific date ranges and room/rate combinations.

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.

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.

  • Can update availability, restrictions, or both simultaneously.

  • Can target room level (InvTypeCode only) or room rate level (InvTypeCode + RatePlanCode).

Restriction Independence

  • Each restriction type (Stop Sell, CTA, CTD, MinLOS, MaxLOS) operates independently, updating one restriction does not change or reset other restrictions.

  • Only include the specific restrictions you want to change - unchanged restrictions retain their current values.

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 (availability) or one room/rate combination (restrictions).

  • Use day-of-week flags to handle weekday/weekend variations within the same date range.

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

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

Update Multiple Values Examples

Each AvailStatusMessage can be used to set Availability, Minimum/Maximum Stays, CTA/CTD and Stop Sells either individually or in combination. Each attribute—such as BookingLimit for availability, LengthOfStay for minimum/maximum stays, and RestrictionStatus for stop sells and CTA/CTD—can be updated independently within the same request.

If you choose to send Stop Sell, CTA and CTD on a Room Level (RatePlanCode not present), then all updates (Open and Close) should follow the same rule. The same applies if you choose to send the restrictions at a room rate level (InvTypeCode and RatePlanCode are present). It is not acceptable to send Room-level restriction updates, and then overlay them with Room Rate level updates or vice versa.

Here is an example of an OTA_HotelAvailNotifRQ that updates only Availability for the same room in a single request:

<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>
Element / @Attribute
Type
M
Description

OTA_HotelAvailNotifRQ

Element

1

Root element for the request.

@xmlns

String

1

Defines the XML namespace for the request. Will be set to http://www.opentravel.org/OTA/2003/05

@EchoToken

String

1

Unique identifier for the request, used to match requests and responses.

@TimeStamp

DateTime

1

Time when the request was generated.

@Version

String

1

Specifies the API version. Will be set to 1.0.

POS / Source / RequestorID

1

@Type

1

Fixed at 22 (ESRP)

@ID

String

AvailStatusMessages

Element

1

Container for availability and restriction status messages.

@HotelCode

String

1

Identifier for the hotel.

AvailStatusMessage

Element

1..n

Single availability or restriction status message.

@BookingLimit

Integer ≥ 0

0..1

Sets the number of rooms available for sale.

StatusApplicationControl

Element

1

Contains date and room identification information. Note: No overlapping dates allowed.

@Start

Date

1

The start date for which the update is being set. This date is inclusive.

@End

Date

1

The end date for which the update is being set. This date is inclusive.

@InvTypeCode

String

0..1

Identifies the room type.

@RatePlanCode

String

0..1

Identifies the rate plan.

Mon, Tue, Weds, Thur, Fri, Sat, Sun

Boolean

0..1

The day-of-week indicators are used to specify which days a rate update applies to. These indicators accept values of "0" or "1", where:

  • "1" indicates the update applies to that day.

  • "0" indicates the update does not apply to that day.

LengthsOfStay

Element

0..1

Used for Minimum Stay and Maximum Stay.

LengthOfStay

Element

1..2

Single length of stay information.

@MinMaxMessageType

String

1

Can be one of the following: SetMinLOS

SetMaxLOS

@Time

Integer > 0

1

Specifies the number of days related to a stay.

SetMinLOS : Minimum days required for a stay.

SetMaxLOS : Maximum days bookable.

@Time value must be above 0. To removeMaxLOS), set @Time to 999.

RestrictionStatus

Element

0..1

Used to restrict the room for Stop Sell, Closed to Arrivals, and Closed to Departure.

@Status

String

1

Values:

Open (opens room for sale)

Close (closes room for sale)

@Restriction

String

0..1

Values:

Arrival (closes to arrival)

Departure (closes to departure)

If no type is specified, assume a full close or open for the room rate.

2. Confirmation Response

<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>
Element / @Attribute
Type
M
Description

OTA_HotelAvailNotifRS

Element

1

Root element for the response.

@xmlns

String

1

Defines the XML namespace for the request. Will be set to http://www.opentravel.org/OTA/2003/05

@EchoToken

String

1

Unique identifier for the request, used to match requests and responses.

@TimeStamp

DateTime

1

Time when the response was generated.

@Version

String

1

Specifies the API version. Must be set to 1.0.

Success

Element

0..1

Indicates successful processing of the request.

Errors

Element

0..1

Indicates an error occurred during the processing of the request.

Error

Element

1..n

Single error information containing free text.

@Type

Integer

1

Type of error. Refer to Error Warning Types (EWT).

@Code

Integer

0..1

Code representing the error. Refer to Error Codes (ERR).

Common Questions

Can I send availability and restrictions updates in the same message?

Yes, but send them separately for better processing.

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

How often should I send availability and restrictions updates?

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.

Can I send full flushes daily to ensure complete synchronization?

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.

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

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.

What happens when availability and restrictions conflict?

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.

Can I set different restrictions for different rate plans on the same room type?

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)

Does SiteMinder automatically reduce availability for all reservation types?

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.

How many dates in advance does SiteMinder support?

Up to 750 days in the future.

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

Do you support Minimum/Maximum Stay Through?

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.

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

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.

Help Centre

Testing and Certification
Error Handling
Glossary

Last updated

Was this helpful?