Document Change Log

official release

All sample files and the snippets embedded in this document were reworked for this release: dates were rebased, the two were realigned where they had drifted apart, and the root Version attribute now carries the OTA2015A version of the message it appears on (see section 3.5)

New samples cover features that were described but never shown: the follow-up response to an acknowledgment, rate plan joining, special offers, Overlay and Remove messages, the out-of-order and out-of-market counts, availability for specific rooms, and the alternative forms of Commission and CardNumber

The AlpineBits ABH and ABR code lists are now used in the Inventory samples

The examples now describe one single property throughout: every sample addresses HotelCode 123 "AlpineBits Hotel", and its room categories are named SINGLE, DOUBLE, SUITE and PITCH in every action, as section 4.1.1 requires; the renaming example of section 4.3.1 follows suit, showing EZ renamed to SINGLE and DZ to DOUBLE

GuestRequests: the push response was described as carrying zero or more HotelReservation elements, a cardinality no valid message ever had: both the AlpineBits^® schema and OTA2015A require at least one. The document now says one or more

GuestRequests: the original booking ID, assigned by the system where the guest completed the reservation, can be transmitted in a HotelReservationID element with ResID_Type 14, next to the ID assigned by the channel manager in UniqueID

GuestRequests: the End attribute of TimeSpan is now explicitly exclusive (it is the departure date), both in RoomStay and in Service; ExpireDateExclusiveInd is documented as optional, defaulting to false; seven examples show the valid combinations of TimeSpan, Start and End in a Service

RatePlans: the algorithm of section 4.4.2 "Computing the cost of a stay" was restructured: the guests are first classified as adults or children according to the first OfferRule element (new step 0), then all the bookability checks are performed on the resulting numbers of adults and children and before any transformation (steps 1 to 3; the former step 4a is now step 3), then the transformations are applied (steps 4 and 5) and finally the cost is computed (step 6)

Protocol: Removed the multipart/form-data Content-Type of the POST request. The action is now sent in the X-AlpineBits-Action header field and the XML document is sent as the request body with Content-Type set to application/xml. During the transition a server may keep serving earlier versions from the same URL, telling them apart by the Content-Type of the request

Schema: the schema has been aligned with OTA2015A wherever it accepted more than OTA does, so that every document valid against the AlpineBits^® schema is also valid against OTA2015A. Nothing OTA2015A allows was removed: enumerations were restored for RatingSymbol, OffsetDropTime and CardCode; CurrencyCode and the OTA code list attributes got their OTA pattern back; numeric attributes, string lengths and maxOccurs got the upper bounds OTA states; the coordinates of Position and the ignored ID of UniqueID got the length limits OTA states; and DiscountPattern no longer accepts the empty string

Schema: an empty Services, Features, TextItems or OfferRules element, and an empty MultimediaDescriptions element inside a GuestRoom, are no longer valid, because OTA2015A requires at least one child in each of them. For all of them but one the document already prescribed at least one child, and only the schema was wider; the exception is Features, described in section 4.3 as containing zero or more Feature elements, which now requires one (a hotel with no accessibility feature to declare omits the Features element). An empty GuestRooms element is not affected and keeps its documented meaning of removing all room categories of a hotel

Schema: RatePlanCode is now limited to 16 characters everywhere it appears (RatePlans, BaseRates and GuestRequests), down from 64. OTA2015A allows only 16 in a reservation, so a longer code could be published but never reported back

Inventory: inside Policies, the schema now enforces what section 4.3 has always stated, namely that a Policy element carries exactly one policy; the children are declared as a choice, in the order OTA2015A uses. The schema used to accept any combination of them in a single Policy, in an order OTA2015A rejects. Messages following the documented model are unaffected

Inventory: added the optional attribute MaxAdultOccupancy to GuestRoom, with StandardOccupancy ≤ MaxAdultOccupancy ≤ MaxOccupancy, to state how many adults a room category allows; when it is given, the computation of the cost of a stay (section 4.4.2) rejects a stay with more adults

RatePlans: Removed Full as allowed value for RatePlanNotifType, reverting to the use of New

RatePlans: in section 4.4.2 family offers are now applied before children are transformed into adults to reach the minimum number of full-rate payers (steps 4 and 5), where up to 2024-10 the transformation came first. The conditions of a family offer are thus evaluated on the children as classified by the rate plan, and a child who stays free is never transformed into an adult. Note that all the bookability checks are still performed beforehand, in particular the minimum number of adults (MinOccupancy on the Occupancy element with AgeQualifyingCode 10 ("adult")). This new order only makes a difference when a family offer grants a child a free stay before the subsequent transformation (step 5) could turn that child into an adult to reach the minimum number of full-rate payers. This is a purely theoretical scenario: in practice, a family offer is unlikely to ever be meant for such a child. Hotels relying on the previous behaviour have to review their family offers

RatePlans: the static rate must now be transmitted in every message, with RatePlanNotifType New as well as Overlay, where up to 2024-10 it could be transmitted only with New. In an Overlay message it serves for control purposes only: the server should compare it with the rate plan on record and, on a discrepancy, refuse the rates with an error (see sections 4.4.1 and 4.4.3)

Schema: the empty string is no longer accepted for MinMaxMessageType inside an OfferRule, since it is not specified in the OTA standard; the documented values SetMinLOS and SetMaxLOS are unaffected

RatePlans: the pricing of pets, prescribed since release 2022-10, can finally be expressed in a valid message: ALPINEBITS-PETS is now an allowed value for CodeContext and InvType in the schema, and a sample was added

RatePlans: the value that marks the pets’ booking rules and supplements was renamed from ALPINEBITSEXTRA-PETS to ALPINEBITS-PETS: OTA declares InvType as StringLength1to16 and the old spelling is 20 characters long, so no message carrying it could validate against OTA2015A. The reserved InvType value ALPINEBITSEXTRA, which stands for a shared list of common InvCode values that does not exist yet, was renamed to ALPINEBITS at the same time, so that the two AlpineBits^®-specific values of that attribute share one prefix

BaseRates: inside RatePlan, the schema now enforces what section 4.5.1 has always stated, namely that DateRange, RatePlanCandidates and HotelRef are given in that order, at most one each, with HotelRef always present. The schema used to accept them repeated, in any order, and with no HotelRef at all. Messages following the documented model are unaffected

GuestRequests (push): the HotelReservations element of a OTA_HotelResNotifRQ request must carry at least one HotelReservation, where the document previously allowed zero; OTA2015A rejects the empty element. The ReservationsList element of a OTA_ResRetrieveRS response may still be empty, as before

GuestRequests (push): the HotelReservations element of a OTA_HotelResNotifRS response is now optional, as it is in OTA2015A. It was mandatory and requires at least one HotelReservation, so a server that could process none of the requests in a batch had no valid way to acknowledge nothing; it can now omit the element and answer with the warning outcome of section 2.3, listing every refusal in Warnings. The empty element stays invalid. No message valid until now becomes invalid, but clients must be prepared for the element to be absent

GuestRequests: a reservation can now carry all the arriving guests: ResGuests may contain one ResGuest per guest, each identified by the new ResGuestRPH attribute, and each RoomStay may list the guests that occupy it in the new ResGuestRPHs element. ResGuests is now described as optional, as the schema always allowed

GuestRequests: the Profiles element of ResGlobalInfo may now contain up to three ProfileInfo elements, with ProfileType 1 (customer), 3 (company) or 4 (booking channel), and a Profile may contain a Customer element, so that a reservation booked by a company can be described (see the sample GuestRequests-OTA_ResRetrieveRS-allguests-and-company.xml)

GuestRequests (acknowledgement): each HotelReservation of an OTA_NotifReportRQ request may now carry a ResGlobalInfo element with a BasicPropertyInfo element giving the HotelCode (and optionally the HotelName) of the acknowledged reservation, not only its ID

GuestRequests: PaymentCard now has the same definition in the Guarantee of a RoomStay and in DepositPayments. In Guarantee, CardHolderName and the CardCode and ExpireDate attributes are now optional, ExpireDate must be a valid MMYY date where any four digits were accepted, and CardNumber also accepts the Mask, Token and TokenProviderID attributes

GuestRequests and Inventory: the PlainText of BankAcctNumber (in the DepositPayments of a reservation and in the GuaranteePaymentPolicy of HotelInfo) and of BankID (in HotelInfo) now accepts any string of up to 64 characters (e.g. an IBAN), where only up to 19 digits were accepted

GuestRequests: the attributes of DepositPayments, which were untyped, now have a type: GuaranteeTypeCode accepts only 3, 28 and 46, GuaranteeID up to 64 characters, PaymentTransactionTypeCode only charge, reserve and the new value refund (see section 4.2.2 for the rules of a refund), Start a date-time and GuaranteeCode up to 32 characters

GuestRequests: the AddressInfo element of a company profile accepts the optional Language attribute

GuestRequests: the Start and End attributes of the TimeSpan of a Service now accept a date, a time or a date-time (OTA DateOrTimeOrDateTimeType), where only a date-time was accepted

GuestRequests: added two new values for ServiceCategoryCode in Service: PACKAGE for package bookings and RESOURCE for bookable resources with limited availability, such as bicycles or baby monitors. Calculation of AmountAfterTax was added.

official release

RelaxNG has been removed as mandatory schema for AlpineBits^®

GuestRequests: Added support for RoomRates

GuestRequests: Added element Services to specify additional services booked with the reservation

GuestRequests: Extension for Comment to support "additional info"

GuestRequests: Added element DepositPayments for information about payments made with the booking

GuestRequests: Added element Profiles for information about the booking channel

Inventory/Basic: Added custom AlpineBits Room Amenity Types (ABR)

Inventory/HotelInfo: Added custom AlpineBits^® Hotel Amenity Codes (ABH)

Inventory/HotelInfo - Breaking change: Removed attributes CheckInTime and CheckOutTime in element PolicyInfo

Inventory: Added TPA_Extensions for exchanging additional codes based on national/EU regulations (i.e. CIN for Italy)

RatePlans: Capability OTA_HotelRatePlanNotif_accept_full added

RatePlans: Added Full value to attribute RatePlanNotifType to replace New value

Breaking change: Attribute HotelCode is now mandatory while attribute HotelName has become optional

Breaking change: Attributes HotelCode and HotelName must not be case sensitive anymore

official release

Handshake: added a complete handshake example in the introduction

Handshake: added new capability to request a handshake refresh

Handshake: added specification for unsupported versions

GuestRequests: added new action for reservation status update

GuestRequests: enhanced specification on mandatory acknowledgement in case of GuestRequest support

GuestRequests: added specification for newsletter registration

GuestRequests: added possibility for multiple room stays in different timespans in a single request

GuestRequests: breaking change in the indication of pets in SpecialRequests

GuestRequests: extended SpecialRequests for a more generic usage

FreeRooms: added new capability for complete sets

Inventory/HotelInfo: added specification in usage of 3/4 board

RatePlan: added pricing of pets

RatePlan: exended charge type of supplements

Schema: minor restriction fixes

Various textual clarifications and enhancements in specification, best practices and appendix

official release

Data Exchange: added support of all currency codes from the ISO 4217

Data Exchange: added exchange of copyright and license information on multimedia objects like images

GuestRequests: added the possibility for special requests regarding pets

FreeRooms: message changed from OTA_HotelAvailNotif to OTA_HotelInvCountNotif

FreeRooms: changes to capabilities

FreeRooms: added the possibility to exchange information regarding closing seasons and rooms out-of-order

Inventory/HotelInfo: specification for hotel information data has been expanded

RatePlans: new attribute CurrencyCode

Activities: added a new message to exchange information about hotel internal activities

official release

The AlpineBits^® documentation is now edited using a public git repository, see the repository history for detailed changelog

Handshaking: the Housekeeping action has been renamed to Handshaking and the relative chapter has been completely rewritten, also introducing breaking changes. Both server and client can now announce the capabilities they support.

GuestRequests: it is now possible to push the GuestRequests instead of polling them.

GuestRequests/Inventory: a new attribute has been added in order to allow a finer classification of the guest accommodation.

Inventory: added the possibility to exchange references to the online presence of the lodging structure (e.g. social networks, review aggregators, etc.)

RatePlans: the price calculation has been reviewed and simplified

BaseRates: the interaction with the Channel Managers has been clarified and simplified

Servers can now request the client to send a full data set in case of suspected mis-alignment of data

official release

The AlpineBits^® documentation is now released under the Creative Commons Attribution-ShareAlike 3.0 Unported License

The attached Trademark policy is now an integral part of the AlpineBits^® specifications

Chapter 2: added version handshake best practices

FreeRooms: added transmission of number of bookable rooms, added purge of stale data

Inventory: heavily updated and refactored

GuestRequests: added Commission element, added encrypted credit card numbers and made card holder name optional, added hints on how to fill ReservationID

RatePlans: added static rates, added supplements that are only available on given days of the week and supplements that depend on room category, improved and extended offers, added SetForwardMinStay and SetForwardMaxStay, extended descriptions and improved their documentation

new action: BaseRates

added general support of HTML in descriptions as an additional format (with some warnings)

minor textual improvements

Appendix A: common section about server response outcomes

Appendix C: compatibility to previous versions described

Appendix D: updated links to OTA2015A standard resources

removed SimplePackages

official release

RatePlans: Section 4.5 has been rewritten to clarify details that the previous version just skipped over, including a detailed description of the price calculation algorithm

RatePlans: new optional capability OTA_HotelRatePlanNotif_accept_RatePlanJoin to allow displaying alternative treatments for the same price list

schema updates and validation: explicitly forbid some values (e.g. base prices of 0 EUR) and limit length of some attributes

minor fixes and clarifications

official release

OTA compatibility: version 2015A is now used

GuestRequests: a series to modifications and additions to make it more flexible especially for reservations

GuestRequests: added refusals (warnings)

GuestRequests: added booking modifications (ResStatus = 'Modify')

RatePlans: changes to capabilities

RatePlans: some clarifications and small additions

RatePlans: partial rewrite and better explanation of Supplements

RatePlans: added the explicit response messages

Inventory: changes to capabilities

Inventory: replaced by OTA_HotelDescriptiveContentNotifRQ

Inventory: added possibility to send multimedia content

Inventory: added additional descriptive content that may be sent separately from the basic data

official release with minor errata fixed

section 4.2.3.: the example was not correct about the fact that the presence of a SelectionCriteria Start requires the server to send the list of inquiries again, regardless whether the client has retrieved them before or not (example fixed and misleading sentence removed)

section 4.1.1: the document did not mention that it is allowed to send a single empty AvailStatusMessage element in a CompleteSet request to reset the room availabilities in a given Hotel - the empty AvailStatusMessage is required for OTA compatibility (this special case is now explicitly mentioned)

section 4.12: in the table at the end of the section the code for “Invalid hotel” was wrongly given as 61 instead of 361 (typo fixed)

section 4.5.2: the document did not mention that it is allowed to send a single empty RatePlan element in a CompleteSet request to reset the rate plans in a given Hotel - the empty RatePlan is required for OTA compatibility (this special case is now explicitly mentioned)

official release

this is a major overhaul of AlpineBits^® - see appendix C.4 for a list of breaking changes, updates and additions

new section: Inventory - room category information

new section: RatePlans

official release

Section 2 (HTTPS layer): added information regarding the new X-AlpineBits-ClientID and X-AlpineBits-ClientProtocolVersion fields in the HTTP header

Section 3.2 (capabilities): added capability for FreeRooms deltas

Section 4 (Intro): changed the text a bit to make it clearer that AlpineBits^® does indeed support booking requests and not only requests for quotes

Section 4.1 (FreeRooms): added the possibility to send partial information (deltas); added warning response; much improved description of the response in general

Section 4.2 (GuestRequests): slightly improved the description of the response in case of error

Section 4.3 (Simple Packages): added limitation (just one Hotel per request); added warning response; much improved description of the response in general; clarified text to explicitly state that it is not allowed to mix package add and delete requests in a single message

Appendix B: this document should be language neutral so the code that used to be here has been removed with a message to check the official AlpineBits^® site (with the current release the code is still in the documentation kit, however)

Appendix C: new appendix

official release

OTA compatibility: the attribute Thu is renamed to Thur and the attribute Wed is renamed to Weds

SimplePackages: the element Image is listed as mandatory in the table as it already was in the text and schema files

SimplePackages: The element RateDescription is listed as non-repeatable in the table as it already was in the text and schema files

official release

major rewrite of the text

FreeRooms: action OTA_HotelAvailNotif is no longer mandatory

GuestRequests: reservation inquiries

SimplePackages: package availability notifications