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
SiteMinder will provide a single global endpoint for all hotels for PMS to send update requests
OTA_HotelAvailNotifRQ
and receive confirmation responsesOTA_HotelAvailNotifRS
.
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.
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.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.
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.
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>
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>
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.
Help Centre
Last updated
Was this helpful?