Help CentrePartner ContactsTest Extranet LoginBecome a SiteMinder Partner

Availability and Restrictions

Sync room inventory and booking restrictions from SiteMinder Platform to your booking channel.

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.

Web Service Endpoint

  • The booking channel will provide a single global endpoint for all hotels for SiteMinder to push OTA_HotelAvailNotifRQ messages and receive OTA_HotelAvailNotifRS responses indicating success or failure.

  • The endpoint must use a registered domain name.

  • Direct IP addresses are not supported and cannot be used as endpoints.

Authentication

  • The booking channel will provide a single username/password for all hotels.

  • SiteMinder will include authentication credentials within the SOAP Security header of each OTA_HotelAvailNotifRQ.

  • 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., ! @ # ? ]).

  • Do not use < > & " ' as they can cause issues with the Web Service.

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

  • SiteMinder sends requests over port 443.

IP Whitelisting

Pre-Production IP addresses:

52.13.134.140

34.213.128.113

35.164.250.223 Production IP addresses will be provided during go-live.

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.

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

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

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.

To enable Min/Max Stay Through, the booking channel must also support Min/Max Stay On Arrival.

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

AvailStatusMessages

Element

1

Container for availability status messages.

@HotelCode

String

1

Identifier for the hotel.

AvailStatusMessage

Element

1

Single availability status message.

@BookingLimit

Integer

1

Sets the number of rooms available for sale.

StatusApplicationControl

Element

1

Contains date and room identification information.

@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

1

Identifies the room.

@RatePlanCode

String

1

Identifies the rate.

LengthsOfStay

Element

0..2

Used for Minimum Stay and Maximum Stay.

LengthOfStay

Element

1

Single length of stay information.

@MinMaxMessageType

String

1

Can be one of the following:

SetMinLOS

SetMaxLOS

SetForwardMinStay

SetForwardMaxStay

@Time

Integer

0..1

Specifies the number of days related to a stay. Valid range: 1 to 9999. Minimum Stay: Always included with minimum value of 1. Maximum Stay: When included: Set or update the maximum stay value. When excluded: Remove/clear any existing maximum stay restriction.

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

2. Confirmation Response

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

What updates can be sent in a single message?

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.

How often will I receive availability and restriction updates?

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.

What's the difference between Room Type level and Rate Plan level availability?

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.

Is there a mechanism to prevent hotels from entering excessively large availability numbers?

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.

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

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.

What's the difference between Stay on Arrival and Stay Through?

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.

What happens if I don't support certain restriction types?

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.

What are the date range limitations for updates?

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.

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

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.

How do I handle MaxStay updates without a Time attribute?

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.

Help Centre

Testing and Certification
Error Handling
Glossary

Last updated

Was this helpful?