Skip to main content
Complete summary of all general real-time messaging concepts. Check this section and implement the needed features.

​
Languages

A language may be specified for any descriptive texts returned in real-time responses. Supported across NBC, Hotel, Transfer, and Excursion messaging.
Example for German
<OTA_HotelDescriptiveInfoRQ PrimaryLangID="DE" AltLangID="EN" ...>
<OTA_HotelAvailRQ PrimaryLangID="DE" AltLangID="EN" ...>
<OTA_GroundAvailRQ PrimaryLangID="DE" AltLangID="EN" ...>
<OTA_TourActivitySearchRQ PrimaryLangID="DE" AltLangID="EN" ...>
  • If PrimaryLangID is not specified, default is 'EN'.
  • If AltLangID is not specified, default is 'EN'.
  • If description for PrimaryLangID exists, it is used; otherwise AltLangID is used.
  • If neither exists, no description is returned.
Language Coverage (ISO 639-1):
  • Hotel Main Description: CS, DA, DE, EN, ES, FI, FR, HU, IT, NB, NL, NO, PL, PT, SV, RU, TR, IS, CZ, ZH
  • Room Descriptions: DE, DA, EN, ES, FI, FR, HU, IT, NL, NO, PL, PT, SV, RU, TR
  • Facts: EN

​
Currencies

Your ClientID can be configured to deliver prices in a single currency or in the original currency of the agreement with the provider. Supported Currencies (ISO 4217): EUR, USD, AED, BGN, BRL, CAD, CHF, CVE, DKK, DOP, EGP, GBP, HRK, MAD, MXN Currency Settings Each RequestorID can have one of two currency settings:
  • Selling Currency: Prices are converted to a fixed currency (e.g., EUR).
  • Contract Currency = Client Currency: No conversion; partner handles it.
OTA response (OTA_HotelAvailRS) may contain mixed currencies.

​
InSeries

For synchronous (less than 5 seconds) processing of multiple commits (e.g., hotel + transfer), include TransactionStatusCode="InSeries" in the root element of every message. This property enables a synchronous processing of the message, so it is necessary to wait until the response before sending a related commit message.
Example
<OTA_HotelResRQ xmlns="http://www.opentravel.org/OTA/2003/05"
EchoToken="1" ResStatus="Commit" Version="2016.2" TransactionStatusCode="InSeries">
This delays the response (aprox. 1 second) until the booking is saved and ready for the next step. Only valid for Commit messages.

​
Master and Child References

This functionality improves booking management and packaging services at the booking level. Each booking includes:
  • One Master Reference (Super PNR)
  • Multiple Child References (one per booking item)
Master Reference
  • Purpose: Represents the entire booking and packages all items (e.g., hotel, transfer, excursion).
  • Impact: Actions on the master reference affect all items (e.g., retrieve, cancel).
Identification
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
Child Reference
  • Purpose: Represents individual booking items (e.g., a room or a transfer).
  • Relation: Linked to items using RPH values.
Identification
<UniqueID Type="37" ID_Context="Client" ID="aaa1"/>
Example: Hotel Booking with 2 Rooms
Request (OTA_HotelResRQ)
<RoomStay RPH="1">...</RoomStay>
<RoomStay RPH="2">...</RoomStay>
<HotelReservationID ResID_SourceContext="Client" ResID_Type="36" ResID_Value="AAA"/>
<HotelReservationID ResID_SourceContext="Client" ResID_Type="37" ResID_Value="aaa1" Item_RPH="1"/>
<HotelReservationID ResID_SourceContext="Client" ResID_Type="37" ResID_Value="aaa2" Item_RPH="2"/>
Response (OTA_HotelResRS)
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
<UniqueID Type="36" ID_Context="Internal" ID="TK1234567890"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa1"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1234"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa2"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1235"/>
Example: Transfer Booking
Request (OTA_GroundBookRQ)
<Location RPH="1">...</Location>
<Location RPH="2">...</Location>
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa3" Item_RPH="1"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa4" Item_RPH="2"/>
Response (OTA_GroundBookRS)
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
<UniqueID Type="36" ID_Context="Internal" ID="TK1234567890"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa3"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1236"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa4"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1237"/>
Booking Retrieval
Request (OTA_ReadRQ)
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
Response (OTA_ResRetrieveRS)
<UniqueID Type="36" ID_Context="Client" ID="AAA"/>
<UniqueID Type="36" ID_Context="Internal" ID="TK1234567890"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa1"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1234"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa2"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1235"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa3"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1236"/>
<UniqueID Type="37" ID_Context="Client" ID="aaa4"/>
<UniqueID Type="37" ID_Context="Internal" ID="1234_1237"/>
Rules and Constraints
  • Duplicate child references for the same master reference will result in an error.
  • If only a master reference is provided, child references will be auto-generated and returned in the response.
  • RPH values must be unique across different message types within the same booking.
  • Reference ID Length: Max 20 characters (not 64 as per OTA).
  • Allowed Characters:
    • Digits: 0–9
    • Letters: A–Z
    • Symbols: ~, - (non-HTTP/XML restricted)

​
Non-Refundable Rooms

Rooms with 100% cancellation penalty from the moment of booking. Identification:
  • Room code includes promo code N
  • Description includes “Non-Refundable”
  • DRV code includes AT04-NRF
It is reccommended to identify these rooms via the room code (Promo code N)
Example
<RoomType RoomTypeCode="RMSD00000N">
<RoomDescription>
  <Text Language="EN">Room_Standard/Non-Refundable</Text>
</RoomDescription>
Semi-non-refundable rooms may include grace periods and use OffsetDropTime="AfterBooking".

​
Vendor Messages

Important room-specific information in responses. This information shall be processed and/or shown to the end customer. These messages include concepts like non-refundable rooms, offer tags, incidents and erratas, complimentary extras, etc. Each type of message is identified using the InfoType property, an OTA INF (Information Type) code. InfoType Codes:
Examples
<VendorMessages>
    <VendorMessage Title="IncidentsAndErrata" InfoType="12">
    <SubSection>
        <Paragraph>
        <Text>No Restaurant, Comment: Only main restaurant at annex open during winter, Distance: 500 m, Action: at nearby restaurant</Text>
        </Paragraph>
    </SubSection>
    </VendorMessage>
    <VendorMessage Title="CancellationConditions" InfoType="2">
        <SubSection>
            <Paragraph>
                <Text>Non refundable room</Text>
            </Paragraph>
        </SubSection>
    </VendorMessage>
</VendorMessages>
These messages can also use DRV codes from Deutscher Reiseverband.
Example
<VendorMessages>
    <VendorMessage Title="FreeCancellationConditions" InfoType="2">
        <SubSection SubTitle="FCP-RATE" SubCode="DRV"/>
        <SubSection SubTitle="FCB-P0H" SubCode="DRV"/>
    </VendorMessage>
</VendorMessages>

​
Offer Tags and Extras

Returned in search and booking responses for promotional purposes as Vendor Messages.
  • InfoType 3: Offers
  • InfoType 5: Extras
Example
<VendorMessage Title="Early Booking" InfoType="3">
  <SubSection SubCode="Value" SubTitle="20%">
    <Paragraph>
      <Text>Early Booking 20%</Text>
    </Paragraph>
  </SubSection>
</VendorMessage>

​
The offer and extra codes that contain the attribute CodeContext=”DRV” use GlobalTypes from the Deutscher Reiseverband.

​
Message Compression

Mandatory for communication with webservices.
  • Based on HTTP gzip compression.
  • Enable via HTTP header: Accept-Encoding: gzip
See RFC2616 and RFC1952.

​
Provider Identification

Provider info is included in all messages under TPA_extensions. This extra information can be used for mapping purposes and future multi provider products.
Example
<POS>
  <Source>
    <RequestorID ID_Context="AxisData" Type="47">
      <CompanyName Code="OTS" CompanyShortName="Open Travel Service AG"/>
    </RequestorID>
  </Source>
</POS>

​
Transaction Control

In order to identify all messages related to a specific transaction, all messages in the same transaction should use the same EchoToken.
Example
<OTA_HotelAvailRQ xmlns="http://www.opentravel.org/OTA/2003/05"
EchoToken="807e760a7257422c8313f1b19651e112">

​
Packaging

The interface supports two main package models:
  • Pre-Packaged
  • Dynamic Package

​
Pre-Packaged Model

In this model, two or more services are offered together. Services are grouped in two ways: 1. Combination of Products
  • Example: Hotel + Rent-a-Car
  • These combinations form a new room with a unique inventory code.
  • Hotel codes include a 2-character extension:
    • AR = Accommodation + Rent-a-Car
    • AG = Accommodation + Golf
  • Car packages are notified as an additional inventory code at room level.
  • Car codes follow the ACRISS standard and are listed in Appendix H.
  • Car codes per hotel can be retrieved from the services section of the OTA_HotelDescriptiveInfo message using the SUMMARY template.
  • Prices and availability for room + car packages are available:
    • In notification messages (Notification Model)
    • In search results (Transactional Model)
Other examples of packages on sale include:
  • Schlagersterne Festival in Mallorca
  • Island Hopping in Greece
  • Fly & Drive in the Algarve
  • Blue Cruises in Turkey
  • Nile Cruises in Egypt
2. Hotel-Supplied Extras
  • Offered as a different room code containing a compulsory extra (e.g., spa treatments).
  • Commonly used for hotel-provided offers.
  • Disadvantages:
    • Poor visibility of room descriptions in the German market.
    • Dependency on room descriptions in search results in other markets.
Packages with optional services (e.g., ski pass, ski lessons, ski equipment rental) are often included as a RatePlan, allowing dynamic pricing and allotment from the normal hotel contract.

​
Dynamic Package Model

In this model, any service offered within the interface (hotel, transfer, rent-a-car, excursion) can be booked into a single booking, creating a package.
  • Uses master and child references to group services.
  • Allows services to be added or cancelled individually.

​
Price Breakdown

Add Instance="PriceBreakdown" to RequestorID to receive detailed pricing.
Example
<RequestorID ID_Context="AxisData" Instance="PriceBreakdown" Type="22" ID="TST1"/>
Returned in TPA_Extensions > RateDetails. Includes:
  • Per pax/day breakdown
  • Codes like AA, AI, AP, EX, EBO2

​
Payment Identification

The Payment ID is added to the booking request during the booking commit post-process by including BillingInstructionCode structures. These structures support various payment scenarios: Single Payment for All Passengers A single payment covers the entire booking and all its items.
Example
<BillingInstructionCode BillingCode="xxxxx" AuthorizationCode="yyyyyy1" AccountNumber="WireCard">
  <ResGuestRPH RPH="1"/>
  <ResGuestRPH RPH="2"/>
  <ResGuestRPH RPH="3"/>
  <ResGuestRPH RPH="4"/>
</BillingInstructionCode>
One Payment per Passenger Each passenger makes a separate payment that covers all items assigned to them. The same BillingCode is used, but each entry is specific to one passenger.
Example
<BillingInstructionCode BillingCode="xxxxx" AuthorizationCode="yyyyyy1" AccountNumber="WireCard">
  <ResGuestRPH RPH="1"/>
</BillingInstructionCode>
<BillingInstructionCode BillingCode="xxxxx" AuthorizationCode="yyyyyy2" AccountNumber="WireCard">
  <ResGuestRPH RPH="2"/>
</BillingInstructionCode>
<BillingInstructionCode BillingCode="xxxxx" AuthorizationCode="yyyyyy3" AccountNumber="WireCard">
  <ResGuestRPH RPH="3"/>
</BillingInstructionCode>
<BillingInstructionCode BillingCode="xxxxx" AuthorizationCode="yyyyyy4" AccountNumber="WireCard">
  <ResGuestRPH RPH="4"/>
</BillingInstructionCode>
Grouped Payments (e.g., 2 Payments for 2 Rooms) Payments are split between groups of passengers. For example, each couple pays for their room.
Example
<BillingInstructionCode BillingCode="xxxxx1" AuthorizationCode="yyyyyy1" AccountNumber="WireCard">
  <ResGuestRPH RPH="1"/>
  <ResGuestRPH RPH="2"/>
</BillingInstructionCode>
<BillingInstructionCode BillingCode="xxxxx2" AuthorizationCode="yyyyyy2" AccountNumber="WireCard">
  <ResGuestRPH RPH="3"/>
  <ResGuestRPH RPH="4"/>
</BillingInstructionCode>
  • Each passenger (ResGuestRPH) is linked to specific booking items.
  • Payments are directly related to the items assigned to each passenger.
  • Partners must use master/child reference logic to ensure correct linkage.
  • Contact the integrations department before implementing this concept.

​
Date/Time Formats

In various places we specify deadlines for specific concepts. For example the absolute deadline in cancellation policies or early booking discount prepayment. All these concepts use the local system time of our servers hosted on premises in ZRH and in our ZRH based AWS cloud. All Date/Time fields are in CET.
Example
<HotelReservation CreateDateTime="2023-02-17T17:33:33">
<CancelPenalty Item_RPH="0">
  <Deadline OffsetUnitMultiplier="3" OffsetTimeUnit="Day"
  OffsetDropTime="BeforeArrival" AbsoluteDeadline="2023-03-31T00:00:00"/>
</CancelPenalty>
It is important to consider this also for making a booking when release is concerned: making a booking at 7PM PST for arrival today, means for our system that you specify yesterday as in CET it is already 4AM the next day and conclusively our system will not allow a booking for arrival “yesterday”.