Open Travel 2017B Message Users Guide

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 144 [warning: Documents this large are best viewed by clicking the View PDF Link!]

---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
OpenTravel Alliance
Message Users Guide
2017B, Version 1, November 2017
The OpenTravel Alliance (OpenTravel) offers this publication for use at the discretion of the individual or com-
pany. Each individual or company that uses this material does so at its own risk and with the acknowledgment
that the individual or company is solely and fully responsible for its use of this material.
Intellectual Property Statement: OpenTravel is a travel industry community effort to develop voluntary
XML-based communications specifications and thereby facilitate the use of electronic commerce in our industry.
These specifications are developed through a consensus building process that encourages the active participation
of all Member Companies’ representatives. Suggestions made at OpenTravel meetings are therefore likely to be
included in OpenTravel specifications. Member companies and potential member companies should be aware of
this and closely review the membership agreement. OpenTravel is the owner of OpenTravel specifications, and
each member company grants the OpenTravel Alliance the right to sublicense to other member companies, their
affiliates, and end users, a non-exclusive, royalty-free license as defined in the membership agreement.
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
Contents
Introduction and Getting Started with the OpenTravel Specification ..................................................... 21
Introducing the OpenTravel Alliance ................................................................................................................. 21
OpenTravel Alliance Resources ........................................................................................................................ 21
OpenTravel Specification Components ............................................................................................................. 22
Basic OpenTravel Schema Concepts ......................................................................................................... 23
OpenTravel Schema Design Best Practices ..................................................................................................... 23
OpenTravel Message Exchange Patterns......................................................................................................... 23
Request/Response Pattern ........................................................................................................................... 23
Notif Pattern .................................................................................................................................................. 23
Generic Messages ........................................................................................................................................ 24
Payload Transaction Management .................................................................................................................... 24
OpenTravel File Naming Conventions .............................................................................................................. 26
OpenTravel Code Lists and Enumerations ....................................................................................................... 26
External Code Lists ........................................................................................................................................... 27
External Codes Lists & Other References in OpenTravel Schema .............................................................. 27
OpenTravel Message Success, Warnings & Errors Elements .......................................................................... 28
Schema Architecture ......................................................................................................................................... 29
Understanding OpenTravel Schema Architecture......................................................................................... 29
OpenTravel Message Level Schema ............................................................................................................ 30
OpenTravel Industry Common Types Schema ............................................................................................. 30
OpenTravel Common Types Schema ........................................................................................................... 30
OpenTravel Simple Types Schema............................................................................................................... 30
OpenTravel Message Transport .................................................................................................................. 31
Introduction ........................................................................................................................................................ 31
Definitions & Conventions ................................................................................................................................. 31
State Maintenance ............................................................................................................................................. 31
SOAP Messaging .............................................................................................................................................. 32
Purpose ......................................................................................................................................................... 32
The SOAP Transport Protocol ...................................................................................................................... 32
The Need for Interoperability ........................................................................................................................ 33
Guidelines for OpenTravel Documents & Messages ........................................................................................ 35
SOAP Version 1.1 and 1.2 ............................................................................................................................ 35
SOAP Messaging and SOAP RPC ................................................................................................................... 36
Differences between SOAP Messaging and SOAP RPC ............................................................................. 36
WSDL Document/ Literal Binding ................................................................................................................. 36
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
SOAP Messaging Benefits ............................................................................................................................ 37
SOAP Messaging vs. RPC Guidelines ......................................................................................................... 37
SOAP Action URI .......................................................................................................................................... 37
SOAP Messaging and the SOAP Action URI................................................................................................ 37
SOAP Intermediaries .................................................................................................................................... 37
SOAP Action URI Guidelines ........................................................................................................................ 38
SOAP Envelope Content .............................................................................................................................. 38
SOAP Header Content .................................................................................................................................. 38
SOAP Body Content ..................................................................................................................................... 39
SOAP Attachments ....................................................................................................................................... 39
SOAP Fault vs. OpenTravel Error ................................................................................................................. 39
Examples ...................................................................................................................................................... 40
HTTP Messaging ............................................................................................................................................... 50
Background ................................................................................................................................................... 50
The Need for Interoperability ........................................................................................................................ 50
GENERIC MESSAGES .................................................................................................................................. 56
Messages Overview .......................................................................................................................................... 56
Messages List ................................................................................................................................................... 56
OTA_AuthorizationRQ/RS ................................................................................................................................. 57
Message Pair Overview ................................................................................................................................ 57
OTA_CancelRQ/RS ........................................................................................................................................... 57
Message Pair Overview ................................................................................................................................ 57
OTA_DeleteRQ/RS............................................................................................................................................ 58
Message Pair Overview ................................................................................................................................ 58
OTA_ErrorRS .................................................................................................................................................... 58
Message Pair Overview ................................................................................................................................ 58
OTA_FileAttachmentNotifRQ/RS ...................................................................................................................... 59
Message Pair Overview ................................................................................................................................ 59
OTA_NotifReportRQ/RS .................................................................................................................................... 59
Message Pair Overview ................................................................................................................................ 59
OTA_PingRQ/RS ............................................................................................................................................... 60
Message Pair Overview ................................................................................................................................ 60
OTA_PurchaseItemRQ/RS ................................................................................................................................ 60
Message Pair Overview ................................................................................................................................ 60
OTA_ReadRQ/OTA_ResRetrieveRS ................................................................................................................ 63
Message Pair Overview ................................................................................................................................ 63
OTA_ReviewsNotifRQ/RS ................................................................................................................................. 64
Message Pair Overview ................................................................................................................................ 64
OTA_ReviewsRQ/RS ........................................................................................................................................ 64
Message Pair Overview ................................................................................................................................ 64
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
OTA_ScreenTextRQ/RS .................................................................................................................................... 64
Message Pair Overview ................................................................................................................................ 64
AIR MESSAGES ............................................................................................................................................ 65
Messages Overview .......................................................................................................................................... 65
Messages List ................................................................................................................................................... 65
OTA_AirAvailRQ/RS .......................................................................................................................................... 67
Message Pair Overview ................................................................................................................................ 67
OTA_AirBaggageRQ/RS ................................................................................................................................... 67
Message Pair Overview ................................................................................................................................ 67
OTA_AirBookRQ/RS ......................................................................................................................................... 68
Message Pair Overview ................................................................................................................................ 68
OTA_AirCheckInRQ/RS .................................................................................................................................... 68
Message Pair Overview ................................................................................................................................ 69
OTA_AirDemandTicketRQ/RS .......................................................................................................................... 69
Message Pair Overview ................................................................................................................................ 69
OTA_AirDisplayQueueRS ................................................................................................................................. 69
Message Pair Overview ................................................................................................................................ 69
OTA_AirFareDisplayRQ/RS .............................................................................................................................. 69
Message Pair Overview ................................................................................................................................ 69
OTA_AirFlifoRQ/RS ........................................................................................................................................... 69
Message Pair Overview ................................................................................................................................ 69
OTA_AirDetailsRQ/RS....................................................................................................................................... 70
Message Pair Overview ................................................................................................................................ 70
OTA_AirLowFareSearchRQ/RS ........................................................................................................................ 70
Message Pair Overview ................................................................................................................................ 70
OTA_AirPriceRQ/RS ......................................................................................................................................... 71
Message Pair Overview ................................................................................................................................ 71
OTA_AirRulesRQ/RS ........................................................................................................................................ 71
Message Pair Overview ................................................................................................................................ 71
OTA_AirScheduleRQ/RS .................................................................................................................................. 71
Message Pair Overview ................................................................................................................................ 71
OTA_AirSeatMapRQ/RS ................................................................................................................................... 72
Message Pair Overview ................................................................................................................................ 72
OTA_AirBookModifyRQ/OTA_AirBookRS ......................................................................................................... 72
Message Pair Overview ................................................................................................................................ 72
OTA_AirGetOfferRQ/RS .................................................................................................................................... 72
Message Pair Overview ................................................................................................................................ 72
CAR MESSAGES .......................................................................................................................................... 74
Messages Overview .......................................................................................................................................... 74
Messages List ................................................................................................................................................... 75
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
OTA_VehAvailRateRQ/RS ................................................................................................................................ 76
Message Pair Overview ................................................................................................................................ 76
OTA_VehCancelRQ/RS .................................................................................................................................... 76
OTA_VehCheckOutRQ/RS ................................................................................................................................ 77
Message Pair Overview ................................................................................................................................ 77
OTA_VehCheckInRQ/RS .................................................................................................................................. 77
Message Pair Overview ................................................................................................................................ 77
OTA_VehLocDetailsNotifRQ/RS ....................................................................................................................... 78
Message Pair Overview ................................................................................................................................ 78
OTA_VehExchangeRQ/RS ................................................................................................................................ 78
Message Pair Overview ................................................................................................................................ 78
OTA_VehLocDetailRQ/RS ................................................................................................................................. 78
Message Pair Overview ................................................................................................................................ 78
OTA_VehLocSearchRQ/RS .............................................................................................................................. 79
Message Pair Overview ................................................................................................................................ 79
OTA_VehModifyRQ/RS ..................................................................................................................................... 79
Message Pair Overview ................................................................................................................................ 79
OTA_VehRateNotifRQ/RS ................................................................................................................................. 80
Message Pair Overview ................................................................................................................................ 80
OTA_VehRateRuleNotifRS/RS .......................................................................................................................... 80
Message Pair Overview ................................................................................................................................ 80
OTA_VehRateRuleRQ/RS ................................................................................................................................. 80
Message Pair Overview ................................................................................................................................ 80
OTA_VehResRQ/RS ......................................................................................................................................... 81
Message Pair Overview ................................................................................................................................ 81
OTA_VehResStatusNotifRQ/RS ........................................................................................................................ 81
Message Pair Overview ................................................................................................................................ 81
OTA_VehRetResRQ/RS .................................................................................................................................... 81
Message Pair Overview ................................................................................................................................ 81
OTA_VehResNotifRQ/RS .................................................................................................................................. 82
Message Pair Overview ................................................................................................................................ 82
CRUISE MESSAGES .................................................................................................................................... 83
Messages Overview .......................................................................................................................................... 83
Messages List ................................................................................................................................................... 84
OTA_CruiseBookingDocumentRQ/RS .............................................................................................................. 85
Message Pair Overview ................................................................................................................................ 85
OTA_ReadRQ/OTA_CruiseBookingHistoryRS ................................................................................................. 85
Message Pair Overview ................................................................................................................................ 85
OTA_CruiseCabinAvailRQ/RS .......................................................................................................................... 85
Message Pair Overview ................................................................................................................................ 85
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
OTA_CruiseCabinHoldRQ/RS ........................................................................................................................... 86
Message Pair Overview ................................................................................................................................ 86
OTA_CruiseCabinUnholdRQ/RS ....................................................................................................................... 86
Message Pair Overview ................................................................................................................................ 86
OTA_CruiseCancellationPricingRQ/RS ............................................................................................................ 86
Message Pair Overview ................................................................................................................................ 86
OTA_CruiseCategoryAvailRQ/RS ..................................................................................................................... 86
Message Pair Overview ................................................................................................................................ 86
OTA_CruiseBookRQ/RS ................................................................................................................................... 87
Message Pair Overview ................................................................................................................................ 87
OTA_CruiseDiningAvailRQ/RS ......................................................................................................................... 87
Message Pair Overview ................................................................................................................................ 87
OTA_CruiseFareAvailRQ/RS ............................................................................................................................ 87
Message Pair Overview ................................................................................................................................ 87
OTA_CruiseFastSellRQ .................................................................................................................................... 88
Message Pair Overview ................................................................................................................................ 88
OTA_CruiseInfoRQ/RS ..................................................................................................................................... 88
Message Pair Overview ................................................................................................................................ 88
OTA_CruiseItineraryDescRQ/RS ...................................................................................................................... 88
Message Pair Overview ................................................................................................................................ 88
OTA_CruisePaymentRQ/RS ............................................................................................................................. 89
Message Pair Overview ................................................................................................................................ 89
OTA_CruisePkgAvailRQ/RS ............................................................................................................................. 89
Message Pair Overview ................................................................................................................................ 89
OTA_CruisePriceBookingRQ/RS ...................................................................................................................... 89
Message Pair Overview ................................................................................................................................ 89
OTA_CruisePNR_UpdateNotifRQ/RS ............................................................................................................... 89
Message Pair Overview ................................................................................................................................ 89
OTA_CruiseSailAvailRQ/RS .............................................................................................................................. 90
Message Pair Overview ................................................................................................................................ 90
OTA_CruiseShorexAvailRQ/RS ........................................................................................................................ 91
Message Pair Overview ................................................................................................................................ 91
OTA_CruiseSpecialServiceAvailRQ/RS ............................................................................................................ 91
Message Pair Overview ................................................................................................................................ 91
DESTINATION ACTIVITY MESSAGES ........................................................................................................ 92
Messages Overview .......................................................................................................................................... 92
Messages List ................................................................................................................................................... 92
OTA_DestActivityCapabilitiesRQ/RS ................................................................................................................ 93
Message Pair Overview ................................................................................................................................ 93
OTA_DestActivityResRQ/RS ............................................................................................................................. 93
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
Message Pair Overview ................................................................................................................................ 93
DYNAMIC PACKAGE MESSAGES .............................................................................................................. 94
Messages Overview .......................................................................................................................................... 94
Messages List ................................................................................................................................................... 94
OTA_DynamicPkgAvailRQ/RS .......................................................................................................................... 94
Message Pair Overview ................................................................................................................................ 94
OTA_DynamicPkgBookRQ/RS ......................................................................................................................... 95
Message Pair Overview ................................................................................................................................ 95
OTA_ReadRQ/OTA_DynamicPkgBookRS........................................................................................................ 95
Message Pair Overview ................................................................................................................................ 95
OTA_DynamicPkgModifyRQ/ OTA_DynamicPkgBookRS ................................................................................ 95
Message Pair Overview ................................................................................................................................ 95
OTA_CancelRQ/OTA_DynamicPkgBookRS ..................................................................................................... 95
Message Pair Overview ................................................................................................................................ 95
OTA_DynamicPkgModifyNotifRQ/RS................................................................................................................ 95
Message Pair Overview ................................................................................................................................ 95
GOLF MESSAGES ........................................................................................................................................ 97
Messages Overview .......................................................................................................................................... 97
Messages List ................................................................................................................................................... 97
OTA_GolfCourseAvailRQ/RS ............................................................................................................................ 98
Message Pair Overview ................................................................................................................................ 98
OTA_GolfFacilityInfoRQ/RS .............................................................................................................................. 98
Message Pair Overview ................................................................................................................................ 98
OTA_GolfRateRQ/RS ........................................................................................................................................ 99
Message Pair Overview ................................................................................................................................ 99
OTA_GolfCourseResRQ/RS ............................................................................................................................. 99
Message Pair Overview ................................................................................................................................ 99
OTA_GolfCourseResModifyRQ/RS................................................................................................................. 100
Message Pair Overview .............................................................................................................................. 100
OTA_GolfCourseSearchRQ/RS ...................................................................................................................... 100
Message Pair Overview .............................................................................................................................. 100
HOTEL MESSAGES .................................................................................................................................... 101
Messages List ................................................................................................................................................. 101
OTA_HotelAvailRQ/RS .................................................................................................................................... 103
Message Pair Overview .............................................................................................................................. 103
OTA_HotelAvailGetRQ/RS .............................................................................................................................. 104
Message Pair Overview .............................................................................................................................. 104
OTA_HotelAvailNotifRQ/RS ............................................................................................................................ 104
Message Pair Overview .............................................................................................................................. 104
OTA_HotelBookingRuleRQ/RS ....................................................................................................................... 105
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
Message Pair Overview .............................................................................................................................. 105
OTA_HotelBookingRuleNotifRQ/RS................................................................................................................ 105
Message Pair Overview .............................................................................................................................. 105
OTA_HotelCacheChangeRQ/RS .................................................................................................................... 106
Message Pair Overview .............................................................................................................................. 106
OTA_HotelInvChangeRQ/RS .......................................................................................................................... 106
Message Pair Overview .............................................................................................................................. 106
OTA_HotelCacheChangeNotifRQ/RS ............................................................................................................. 106
Message Pair Overview .............................................................................................................................. 106
OTA_HotelCommNotifRQ/RS ......................................................................................................................... 107
Message Pair Overview .............................................................................................................................. 107
OTA_HotelDescriptiveContentNotifRQ/RS ..................................................................................................... 107
Message Pair Overview .............................................................................................................................. 107
OTA_HotelDescriptiveInfoRQ/RS .................................................................................................................... 108
Message Pair Overview .............................................................................................................................. 108
OTA_HotelEventRQ/RS .................................................................................................................................. 109
Message Pair Overview .............................................................................................................................. 109
OTA_HotelGetMsgRQ/RS ............................................................................................................................... 109
Message Pair Overview .............................................................................................................................. 109
OTA_HotelInvBlockRQ/RS ............................................................................................................................... 110
Message Pair Overview ............................................................................................................................... 110
OTA_HotelInvBlockNotifRQ/RS ....................................................................................................................... 110
Message Pair Overview ............................................................................................................................... 110
OTA_HotelInvCountRQ/RS .............................................................................................................................. 111
Message Pair Overview ............................................................................................................................... 111
OTA_HotelInvCountNotifRQ/RS ....................................................................................................................... 111
Message Pair Overview ............................................................................................................................... 111
OTA_HotelInvNotifRQ/RS ................................................................................................................................ 112
Message Pair Overview ............................................................................................................................... 112
OTA_HotelPostEventRQ/RS ............................................................................................................................ 112
Message Pair Overview ............................................................................................................................... 112
OTA_HotelPostEventNotifRQ/RS ..................................................................................................................... 113
Message Pair Overview ............................................................................................................................... 113
OTA_HotelProductRQ/RS ................................................................................................................................ 113
Message Pair Overview ............................................................................................................................... 113
OTA_HotelProductNotifRQ/RS ......................................................................................................................... 113
Message Pair Overview ............................................................................................................................... 113
OTA_HotelRateAmountNotifRQ/RS ................................................................................................................. 113
Message Pair Overview ............................................................................................................................... 113
OTA_HotelRatePlanRQ/RS .............................................................................................................................. 114
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
Message Pair Overview ............................................................................................................................... 114
OTA_HotelRatePlanNotifRQ/RS ...................................................................................................................... 114
Message Pair Overview ............................................................................................................................... 114
OTA_HotelResModifyRQ/RS ........................................................................................................................... 115
Message Pair Overview ............................................................................................................................... 115
OTA_HotelResModifyNotifRQ/RS .................................................................................................................... 115
Message Pair Overview ............................................................................................................................... 115
OTA_HotelResNotifRQ/RS ............................................................................................................................... 116
Message Pair Overview ............................................................................................................................... 116
OTA_HotelResRQ/RS ...................................................................................................................................... 116
Message Pair Overview ............................................................................................................................... 116
OTA_HotelRFP_MeetingRQ/RS ...................................................................................................................... 117
Message Pair Overview ............................................................................................................................... 117
OTA_HotelRFP_MeetingNotifRQ/RS ............................................................................................................... 117
Message Pair Overview ............................................................................................................................... 117
OTA_HotelRFP_TransientRQ/RS .................................................................................................................... 118
Message Pair Overview ............................................................................................................................... 118
OTA_HotelRFP_TransientNotifRQ/RS ............................................................................................................. 118
Message Pair Overview ............................................................................................................................... 118
OTA_HotelRoomListRQ/RS ............................................................................................................................. 118
Message Pair Overview ............................................................................................................................... 118
OTA_HotelSearchRQ/RS ................................................................................................................................. 118
Message Pair Overview ............................................................................................................................... 119
OTA_HotelStatsRQ/RS.................................................................................................................................... 120
Message Pair Overview .............................................................................................................................. 120
OTA_HotelStatsNotifRQ/RS ............................................................................................................................ 120
Message Pair Overview .............................................................................................................................. 120
OTA_HotelStayInfoNotifRQ/RS ....................................................................................................................... 121
Message Pair Overview .............................................................................................................................. 121
OTA_HotelSummaryNotifRQ/RS ..................................................................................................................... 121
Message Pair Overview .............................................................................................................................. 121
TRAVEL INSURANCE MESSAGES ........................................................................................................... 122
Messages Overview ........................................................................................................................................ 122
Messages List ................................................................................................................................................. 123
OTA_InsurancePlanSearchRQ/RS ................................................................................................................. 124
Message Pair Overview .............................................................................................................................. 124
OTA_InsuranceQuoteRQ/RS .......................................................................................................................... 124
Message Pair Overview .............................................................................................................................. 124
OTA_InsuranceBookRQ/RS ............................................................................................................................ 124
Message Pair Overview .............................................................................................................................. 124
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
PACKAGE TOUR/ HOLIDAY BOOKING MESSAGES .............................................................................. 125
Messages Overview ........................................................................................................................................ 125
Messages List ................................................................................................................................................. 125
OTA_PkgAvailRQ/RS ...................................................................................................................................... 126
Message Pair Overview .............................................................................................................................. 126
OTA_PkgBookRQ/RS ..................................................................................................................................... 126
Message Pair Overview .............................................................................................................................. 126
OTA_PkgExtrasInfoRQ/RS ............................................................................................................................. 127
Message Pair Overview .............................................................................................................................. 127
OTA_PkgCostRQ/RS ...................................................................................................................................... 127
Message Pair Overview .............................................................................................................................. 127
TOUR/ACTIVITY MESSAGES .................................................................................................................... 128
Messages Overview ........................................................................................................................................ 128
Messages List ................................................................................................................................................. 128
OTA_TourActivityAvailRQ/RS .......................................................................................................................... 129
Message Pair Overview .............................................................................................................................. 129
OTA_TourActivityBookRQ/RS ......................................................................................................................... 129
Message Pair Overview .............................................................................................................................. 129
OTA_TourActivityCancelRQ/RS ...................................................................................................................... 129
Message Pair Overview .............................................................................................................................. 129
OTA_TourActivityModifyRQ ............................................................................................................................. 129
Message Pair Overview .............................................................................................................................. 129
OTA_TourActivityResRetrieveRQ .................................................................................................................... 129
Message Pair Overview .............................................................................................................................. 129
OTA_TourActivitySearchRQ/RS ...................................................................................................................... 129
Message Pair Overview .............................................................................................................................. 129
TRAVEL ITINERARY MESSAGES ............................................................................................................. 130
Messages Overview ........................................................................................................................................ 130
OTA_TravelItineraryReadRQ/OTA_TravelItineraryRS .................................................................................... 131
Message Pair Overview .............................................................................................................................. 131
RAIL MESSAGES ........................................................................................................................................ 132
Messages Overview ........................................................................................................................................ 132
Messages List ................................................................................................................................................. 132
OTA_RailAvailRQ/RS ...................................................................................................................................... 133
Message Pair Overview .............................................................................................................................. 133
OTA_RailBookRQ/RS ..................................................................................................................................... 133
Message Pair Overview .............................................................................................................................. 133
OTA_RailConfirmBookingRQ/RS .................................................................................................................... 134
Message Pair Overview .............................................................................................................................. 134
OTA_RailConfirmBookingRQ Request Message Overview ....................................................................... 134
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
OTA_RailConfirmBookingRS Request Message Overview ........................................................................ 134
OTA_RailFareQuoteRQ/RS ............................................................................................................................ 134
Message Pair Overview .............................................................................................................................. 134
OTA_RailIgnoreBookingRQ/RS ...................................................................................................................... 135
Message Pair Overview .............................................................................................................................. 135
OTA_RailPaymentRQ/RS ............................................................................................................................... 136
Message Pair Overview .............................................................................................................................. 136
OTA_RailPriceRQ/RS ..................................................................................................................................... 136
Message Pair Overview .............................................................................................................................. 136
OTA_ReadRQ/ OTA_RailResRetrieveDetailRS .............................................................................................. 137
Message Pair Overview .............................................................................................................................. 137
OTA_ReadRQ/ OTA_RailResRetrieveSummaryRS ....................................................................................... 138
Message Pair Overview .............................................................................................................................. 138
OTA_RailScheduleRQ/RS ............................................................................................................................... 138
Message Pair Overview .............................................................................................................................. 138
OTA_RailShopRQ/RS ..................................................................................................................................... 139
Message Pair Overview .............................................................................................................................. 139
LOYALTY MESSAGES ................................................................................................................................ 140
Messages Overview ........................................................................................................................................ 140
Messages List ................................................................................................................................................. 140
OTA_LoyaltyAccountCreateRQ/OTA_LoyaltyAccountRS ............................................................................... 141
Message Pair Overview .............................................................................................................................. 141
OTA_LoyaltyCertificateCreateRQ/RS ............................................................................................................. 141
Message Pair Overview .............................................................................................................................. 141
OTA_LoyaltyCertificateCreateNotifRQ/RS ...................................................................................................... 141
Message Pair Overview .............................................................................................................................. 141
OTA_LoyaltyCertificateRedemptionRQ/RS ..................................................................................................... 141
Message Pair Overview .............................................................................................................................. 141
OTA_ReadRQ/OTA_LoyaltyAccountRS.......................................................................................................... 141
Message Pair Overview .............................................................................................................................. 141
PROFILE MESSAGES ................................................................................................................................ 142
Messages Overview ........................................................................................................................................ 142
Messages List ................................................................................................................................................. 142
OTA_ProfileCreateRQ/RS ............................................................................................................................... 143
Message Pair Overview .............................................................................................................................. 143
OTA_ProfileMergeRQ/RS ............................................................................................................................... 143
Message Pair Overview .............................................................................................................................. 143
OTA_ProfileModifyRQ/RS ............................................................................................................................... 143
Message Pair Overview .............................................................................................................................. 143
OTA_ReadRQ/OTA_ProfileReadRS ............................................................................................................... 143
---------------------------------------------------------------------------
© 2016, OpenTravel Alliance. All rights reserved. OpenTravel is a trademark of the OpenTravel Alliance.
Message Pair Overview .............................................................................................................................. 143
GROUND TRANSPORTATION MESSAGES ............................................................................................. 144
Messages Overview ........................................................................................................................................ 144
Messages List ................................................................................................................................................. 145
Implementation Best Practices ........................................................................................................................ 145
OTA_GroundAvailRQ/RS ................................................................................................................................ 147
Message Pair Overview .............................................................................................................................. 147
OTA_GroundResRetrieveRQ/RS .................................................................................................................... 148
Message Pair Overview .............................................................................................................................. 148
OTA_GroundBookRQ/RS ................................................................................................................................ 149
Message Pair Overview .............................................................................................................................. 149
OTA_GroundCancelRQ/RS ............................................................................................................................. 150
Message Pair Overview .............................................................................................................................. 150
OTA_GroundModifyRQ/OTA_GroundBookRS ................................................................................................ 150
Message Pair Overview .............................................................................................................................. 150
OTA_GroundResRetrieveRQ/RS .................................................................................................................... 151
Message Pair Overview .............................................................................................................................. 151
OTA_GroundResNotifRQ/RS .......................................................................................................................... 152
Message Pair Overview .............................................................................................................................. 152
21
© 2013, OpenTravel Alliance. All rights reserved.
Introduction and Getting Started with the OpenTravel
Specification
Introducing the OpenTravel Alliance
The OpenTravel Alliance is passionate about solving the problems inherent in connecting multiple systems with-
in the complex travel distribution arena. OpenTravel's mission is to engineer specifications that make data
transmission flow smoothly throughout travel, tourism and hospitality. OpenTravel creates, expands and drives
adoption of open universal data specifications, including but not limited to the use of XML, for the electronic
exchange of business information among all sectors of the travel industry.
OpenTravel is comprised of companies representing airlines, car rental firms, hotels, cruise lines, railways, lei-
sure suppliers, service providers, tour operators, travel agencies, solutions providers, technology companies and
distributors. OpenTravel is a not-for-profit trade association, founded in 1999 by travel companies, with a pri-
mary focus on the creation of electronic message structures to facilitate communication between the disparate
systems in the global travel industry. Tens of thousands of OpenTravel message structures are in use, carrying
tens of millions of messages between trading partners every day.
OpenTravel Alliance Resources
More information about OpenTravel can be found at:
The OpenTravel Corporate Website (http://www.OpenTravel.org)
Download an OpenTravel Specification
Sign-up for an OpenTravel Webinar
View OpenTravel News & Events
Submit a Comment
The OpenTravel Forum Website (http://www.OpenTravelForum.com/)
Ask a Planning/ Implementation Question
Access OpenTravel Documentation
Subscribe to an OpenTravel Mailing List
See OpenTravel-Enabled Tools/ Products
The OpenTravel Wiki
Access Specification Development & Implementation Resources
Access the OpenTravel Calendar & Publication Schedules
The OpenTravel Alliance on Linked In (http://www.linkedin.com/groups?gid=1053987)
Join the OpenTravel Alliance on Linked in (comprised of individuals from the travel industry)
22
© 2013, OpenTravel Alliance. All rights reserved.
OpenTravel Specification Components
The OpenTravel Message Specification includes the following components:
- The following documents are included with the OpenTravel 2013A Publication:
----------- OpenTravel_CodeTable (folder) -----------
- OpenTravel_CodeList_2012_8_27.zip - A zip file containing the OpenTravel Code Table in Microsoft Excel
format. The OpenTravel Codes List spreadsheet, included with the specification download, includes an alphabet-
ized, point and click list of all OpenTravel Code List names (with 3 character abbreviations) and errors and
warnings to help implementers quickly find code list values.
----------- OpenTravel2013A_XML (folder) -----------
- XML Schema files- OpenTravel XML Schema messages.
----------- OpenTravel_2013A_Schema_Versioning.pdf -----------
- OpenTravel began tracking versions in the 2003B release cycle. Prior to the 2008A release, the version table
contained 2001 and 2002 data for newly created messages. This document contains a table with each OpenTrav-
el message version from 2006A through 2013A.
----------- OpenTravel_2013A_Comments_Report.pdf -----------
- This document contains comments that were entered against the OpenTravel 2012B specification and resulted
in changes to the 2013A specification.
----------- OpenTravel_SchemaDesignBestPracticesV3.08.pdf -----------
- The OpenTravel XML Schema Best Practices document contains documentation about the standards and best
practices used in creating the XML Schemas. Typically, this document is used within the OpenTravel Alliance to
ensure that the creation of XML Schemas is consistent in design across the organization and across releases.
----------- OpenTravel_2013A_XMLMessageSuite_ReleaseNotes.pdf -----------
- The release notes detail the latest information and changes for any given release. This file contains detailed
documentation on changes made between the 2012B release and the 2013A release.
----------- OpenTravel_ImplementationGuide_v1.2_ExecSum.pdf -------------
- This is an executive summary of the OpenTravel Implementation Guide. The purpose of the OpenTravel Im-
plementation Guide is to provide invaluable information to both analysts and implementers of the OpenTravel
specification on how to more easily understand and build software systems that are interoperable with other
travel systems using the OpenTravel schema. The full Guide is available to members of the OpenTravel Alliance
via the Wiki http://wiki.opentravel.org/index.php/Public:Resources.
----------- OpenTravel_FastRez (folder) -----------
- OpenTravel_FastRez.zip: A zipped file containing OpenTravel FastRez Schema, WSDL and User Documenta-
tion.
----------- OpenTravel_Other (folder) -----------
- OpenTravel Hotel Schema Disability Audit Results: An OpenTravel Hotel Disability Project Brief artifact has
been included with the OpenTravel 2011B 1.0 XML Schema Message publication. The OpenTravel Hotel Disabil-
ity project was focused on a subset of the new 2010 ADA legislation that specifically applies to electronic hotel
reservations and includes identifying and describing accessible features; reserving, upon request, accessible
guest rooms or specific types of guest rooms and ensuring that the guest rooms requested are blocked and re-
moved from all reservations systems; and guaranteeing the specific accessible guest room. Per the audit results,
relatively few changes were made to OpenTravel Hotel schema, with one change made to one common hotel
schema (OTA_HotelCommonTypes) to provide a more consistent and structured way to pass measurement in-
formation, and annotation changes made to three hotel schema (OTA_HotelCommonTypes,
OTA_RailCommonTypes and OTA_RailPreferences) to accommodate renaming the OpenTravel Code List Phys-
ically Challenged Feature code table. The slide show included with the publication includes an overview of the
project.
23
© 2013, OpenTravel Alliance. All rights reserved.
Basic OpenTravel Schema Concepts
OpenTravel Schema Design Best Practices
Each XML schema within the OpenTravel specification is built according to a well-defined set of best practices
and design guidelines. These guidelines are described in the OpenTravel Schema Design Best Practices docu-
ment that is included with each OpenTravel publication.
Developers of OpenTravel schema should get familiar with this document because it provides specific instruc-
tions on designing and developing schema enhancements (that meet your specific business processes) and how
to submit them as comments (or as a Project Team Proposal if you are a member company.)
OpenTravel develops and maintains its library of XML schema based on its own specific guidelines so that the
specification as a whole is built against the same set of design principles. This provides several benefits, includ-
ing:
- A coherent OpenTravel specification. Since all OpenTravel XML schema are built according to a single,
coherent set of design principles, the OpenTravel specification as a whole is easier to maintain and use.
- Increased interoperability among travel systems. Since software programs are the ultimate consumers of
the OpenTravel specification, alignment to a shared XML schema design promotes software systems
that are easier to develop and maintain.
- Increased reuse of XML content throughout the specification. Since a consistent set of XML content
types (complex types, simple types, attribute groups, etc.) recurs throughout the specification, the level
of reuse of the XML schema is greatly increased.
OpenTravel Message Exchange Patterns
To accommodate the variations in which data exchanges between trading partners are done, OpenTravel XML
schema support several distinct types of trading partner interactions, known as message exchange patterns.
Each pattern serves a different purpose. For example, one pattern supports requests for information, while an-
other supports the delivery of information to a recipient as shown below:
Request/Response Pattern
This is the most prevalent message exchange pattern supported by the OpenTravel specification and is known as
the request/response pattern. Any transaction that conforms to this pattern will be invoked by one trading part-
ner requesting information explicitly from another party. The requesting party sends a message to the receiver
indicating what data are being requested; this is the request part of the transaction. The receiver then processes
the request and returns the relevant data to the requester; this is the response part of the transaction. You'll find
that most of the message-level XML schema in the OpenTravel specification conform to this exchange pattern
and an example is OTA_CruiseBookRQ (which represents the request) and OTA_CruiseBookRS which repre-
sents the response.
Notif Pattern
This is another message exchange pattern supported by the OpenTravel specification and is known as the notifi-
cation or “notif” pattern. Any transaction that conforms to this pattern involves the delivery of data from one
trading partner to another party without the request to do so. Therefore, this pattern can be understood as a
“push” of data to another party as opposed to a “pull” of data, which describes the request and response pattern.
The sender delivers (pushes) a message to one or more predefined recipients. Any recipient of that message will
then process the data as needed and provide a response back to the sender indicating that the payload was re-
ceived.
24
© 2013, OpenTravel Alliance. All rights reserved.
Generic Messages
In addition to the industry-specific message-level XML schema that constitute the core of the OpenTravel speci-
fication, several other message pairs support generic functions that are not tied to a specific industry or business
process, but, rather, are shared by all industries. Some examples of generic OpenTravel Messages are:
OTA_AuthorizationRQ/RS—which is typically used to verify that a customer’s bank account is valid for pay-
ment, and OTA_CancelRQ/RSwhich are used to cancel all or portions of reservations. This Message Users
Guide contains a list of OpenTravel generic messages with sample use cases.
Payload Transaction Management
Commonly, the first encounter that an OpenTravel specification user has with non-functional requirements is
within the root element of each message. The root element of each message level schema refers to the
OTA_PayloadStdAttributes attribute group. This attribute group is defined in the OTA_CommonTypes file and
contains attributes that, collectively, support common transaction management requirements.
At run-time, these attributes operate within the XML payload rather than the envelope layer. Implementers
should consider carefully their use of these fields as compared to fulfilling the same functionality by way of the
message envelope. The image below depicts the appearance of this attribute group when viewed in an XML
schema editor.
EchoToken. The value of this attribute is assigned by a requesting system and serves as a reference for messag-
es that may follow an initial request. When a request message includes an echo token, the corresponding re-
sponse message must include an echo token with an identical value. This makes it possible for two or more mes-
sages to be correlated together as part of a single transaction.
TimeStamp. This date and time value specifies the creation date and time of a message. This value is UTC for-
mat specified by ISO 8601YYYY-MM-DDThh:mm:ssZwith time values using the 24-hour clock (e.g., 20 No-
vember 2003, 1:59:38 p.m. UTC becomes 2003-11-20T13:59:38).
Target. This enumerated attribute indicates whether a request message is targeted at a test or production sys-
tem.
Version. This decimal value identifies the specific version of the OpenTravel XML schema associated with an
XML instance document. This value makes it possible for trading partners to maintain several versions of the
same schema and correlate instances to the appropriate version.
TransactionIdentifier. This value uniquely identifies a transaction and all messages that make up that trans-
action. This value would be sent in all request and response messages that are part of an ongoing transaction.
25
© 2013, OpenTravel Alliance. All rights reserved.
SequenceNumber. This integer value identifies the sequence number of a transaction. This allows for an ap-
plication to process messages in a certain order or to request a resynchronization of messages in the event that a
system has been offline and needs to retrieve messages that were missed.
TransactionStatusCode. This enumerated attribute indicates where this message falls within a sequence of
messages (Start, End, Rollback, InSeries).
PrimaryLangID. The language code associated with this attribute indicates the primary language for content
provided within an XML instance document. The ability for a message sender to request a particular language
within the response message is not supported by OTA_PayloadStdAttributes.
AltLangID. The language code associated with this attribute specifies the secondary language for content pro-
vided within an XML instance document.
RetransmissionIndicator. This boolean attribute indicates whether a message is being re-sent due to a pre-
viously failed attempt to transmit a message.
The section below depicts a sample XML instance document and its use of several attributes contained within
the OTA_PayloadStdAttributes attribute group.
<?xml version="1.0" encoding="UTF-8"?>
<!-- OPENTRAVEL SAMPLE INSTANCE -->
<!-- USE CASE SCENARIO: #1: One Passenger Ride to Airport for Non-Corporate Account -->
<!-- USE CASE DETAILS:
1. Jane Smith needs ground transportation to an airport and goes to the Academy Limousine site because
they have sent her a 10% off coupon for an airport transfer.
2. From the Academy Limousine website, Jane does an availability request for June 15 at 9:00 AM. (THIS
INSTANCE)
3. Jane receives two ground transportation availability responses, one for an Executive Sedan and one
for a Luxury Sedan. She reviews the pricing, fees, deposit and cancellation information for each
service. (OTA_GroundAvailRS_AirportTransfer.xml)
4. Jane selects the Executive Sedan and books the ground transportation service.
(OTA_GroundBookRQ_AirportTransfer.xml)
5. She receives a booking response that includes the details of her ground transportation reservation.
(OTA_GroundBookRS_AirportTransfer.xml)
6. A week after making the ground transportation reservation, Jane has had to change her flight to be
two hours later (11:00 AM). She phones Academy Limousine to change her reservation, but does not know
her reservation number.
7. The Academy Limousine representative searches for Jane’s reservation by entering her last name and
date of service (OTA_GroundResRetrieveRQ_AirportTransferQuery.xml). She receives 2 responses and
identifies Jane’s reservation (OTA_GroundResRetrieveRS_AirportTransferQuery.xml)
8. The Academy Limousine representative then issues a reservation retrieve request using the
confirmation number returned in step 7 above and receives a detailed reservation response
(OTA_GroundResRetrieveRQ_AirportTransferDetail.xml/ OTA_GroundResRetrieveRS_AirportTransferDetail.xml)
-->
<OTA_GroundAvailRQ xmlns="http://www.opentravel.org/OTA/2003/05"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_GroundAvailRQ.xsd" EchoToken="12345"
TimeStamp="2011-05-01T09:44:52" Target="Production" Version="1.000" PrimaryLangID="en-us">
<!-- Point of sale information for the sender of the availability request. -->
<POS>
<Source>
<RequestorID Type="43" ID="Academy Limousine"/>
<!-- Type 43 = "Ground Transportation Supplier (branded website)". See
OpenTravel Code List Unique ID Type (UIT). -->
</Source>
</POS>
26
© 2013, OpenTravel Alliance. All rights reserved.
OpenTravel File Naming Conventions
Each OpenTravel schema is named according to a standard naming con-
vention that dictates that each file name should be identical to the root
element name within that schema. Therefore, each file begins with an
“OTA_” prefix and concludes with the remainder of the root element
name. For example, the root element name of the “OTA_VehResRQ.xsd”
schema file is “OTA_VehResRQ”.
OpenTravel mandates a naming convention for all XML schema that
model a request and response transaction. For example, the name of all
request messages ends with an “RQ” suffix and the name of all response
messages ends with an “RS” suffix.
Because of this, newcomers to the OpenTravel specification usually find it
relatively easy to identify the XML schema that pertain to a particular
message exchange pattern.
One thing to remember is that OpenTravel schema are named so that the
files associated with each industry (like air, car, hotel and cruise) are cat-
egorized and easily identified for each industry.
OpenTravel Code Lists and Enumerations
XML message exchanges commonly require the ability to restrict a field to a limited set of values.
Business requirements may control this, but
it is often preferred to limit the allowable
values for an element or attribute to as few as
possible to facilitate validation of the values.
To support this need, the OpenTravel specifi-
cation uses XML enumerations and code
lists.
The OpenTravel XML schema contain many
elements and attributes that define the al-
lowable values for the respective field. Enu-
merations are used when the list of values is
static or when it is unlikely that values will be
added. Some examples of this are: Days of
the week and gender.
In addition to complex, simple, and native
data types (string, integer), the OpenTravel
XML schema contain many code values.
Most of these values refer to code lists main-
tained by OpenTravel and each code refers to a specific value contained in one of the code lists. Code lists are
preferred over enumerations when the collection of values they represent are likely to change and grow. The
OpenTravel code lists are included with each OpenTravel Specification publication and, as a whole, are referred
to as the OpenTravel code table. Below you’ll find a sample OpenTravel XML code list reference:
<xs:attribute name="UseType" type="OTA_CodeType" use="optional">
<xs:annotation>
<xs:documentation xml:lang="en">Describes the use of the address (e.g. mail-
ing, delivery, billing, etc.) Refer to OTA Code List Address Use Type
(AUT).</xs:documentation>
</xs:annotation>
</xs:attribute>
27
© 2013, OpenTravel Alliance. All rights reserved.
All code list references in the OpenTravel schema are typed with the OTA_CodeType simple type and the specific
code list associated with an XML attribute is defined within the XML schema annotation for that attribute. For
your benefit, the code table is provided in spreadsheet format as well as in an XML instance.
External Code Lists
In addition to codes maintained by OpenTravel, the OpenTravel XML schema contain some references to code
lists maintained by other standards organizations. The snippet below shows an excerpt from the
OTA_AirCommonTypes schema, which refers to an International Air Transport Association (IATA) location
code:
<xs:attribute name="LocationCode" type="StringLength1to8" use="optional">
<xs:annotation>
<xs:documentation xml:lang="en">A 3 character ATA/IATA city code of telephone
location.</xs:documentation>
</xs:annotation>
</xs:attribute>
Notice that the data type associated with this attribute is not the OTA_CodeType simple type that is used for any
code maintained by OpenTravel. Rather, the StringLength1to8 simple type is used to allow any value of 1 to 8
characters in length. Individual trading partners would be responsible for ensuring that each code passed is a
valid IATA code for example.
External Codes Lists & Other References in OpenTravel Schema
ABTA (Association of British Travel Agents)
ATA (Air Transport Association)
DUNS (Dun & Bradstreet)
ERSP (Electronic Reservation Service Provider - IATA)
IATA (International Airport Transport Association)
ISO (International Organization for Standardization 3166 Country Codes)
ISO (International Organization for Standardization 639 Language Codes)
ISO (International Organization for Standardization 8601 Date Format)
ISO (International Organization for Standardization 4217 Currency Format)
ISO (International Organization for Standardization 6709 Geographic Point Location by Coordinates)
APEX initiative
UIC (International Union of Railways)
28
© 2013, OpenTravel Alliance. All rights reserved.
OpenTravel Message Success, Warnings & Errors Elements
Any OpenTravel message exchange requires that the participating systems have a mechanism to share data
about the processing of that message and whether it was successful or not. The OpenTravel specification ad-
dresses this need by providing a consistent set of elements within all response XML schema. These elements al-
low the responding party to indicate if the message was processed successfully or if any errors or warnings were
encountered.
The elements are:
Success: an element that is not intended to contain
any data. The mere presence of a success element
within a response message indicates that the incoming
message (request or notification) was processed suc-
cessfully.
Warnings: This element indicates that the recipient
of a message identified one or more warnings. A warn-
ing is a business-level error. A warning would be gen-
erated, for example, by a request to book a flight that
does not exist, a request to book a hotel room when
none are available for the dates requested or an incor-
rect message password or requester ID within the re-
quest message. The XML content might be syntacti-
cally valid, but the receiving application cannot fulfill
the request.
Errors: This element indicates that an error occurred
in the processing of an incoming message (request or
notification). An error is defined as a critical error
caused by corruption of a message in transit or a
communication failure. An error would be generated,
for example, by an unforeseen disruption of an appli-
cation or its connection to a trading partner applica-
tion. The data structure of this element is identical to
the Warnings element with the exception of the
NodeList attribute, which provides an XPath expres-
sion that identifies the nodes that caused the error.
Remember that the relationship of these XML schema
elements is significant, because it reflects the response
data structure returned to the sender of an incoming
message. The root element can contain either errors
or other data (success, warnings, or response infor-
mation) and if errors are present, the Errors element
may identify the XML content to which each error
applies.
29
© 2013, OpenTravel Alliance. All rights reserved.
Schema Architecture
Understanding OpenTravel Schema Architecture
The OpenTravel specification is a large collection of XML schema that are organized hierarchically. This design
enables an efficient method for maintaining, understanding, and implementing the specification. It also leverag-
es proven design techniques from XML schema design as well as other software disciplines such as object orien-
tation.
Any data exchange that uses the OpenTravel specification may require content from several messages within the
OpenTravel schema hierarchy. For example, an airline reservation booking message sent from one trading part-
ner may involve validation by an XML schema that includes several other schema. Those files may define much
of the content (e.g., elements, attributes, types) that comprises that booking request message.
Accordingly, an OpenTravel implementer can expect to use a hierarchy of XML schema files, rather than a single
XML schema file, for a given message exchange as shown and described below:
30
© 2013, OpenTravel Alliance. All rights reserved.
OpenTravel Message Level Schema
Each message-level XML schema in the OpenTravel specification represents a particular type of business trans-
action. Some examples of message-level schema are: OTA_AirBookRQ, OTA_HotelResModifyRQ, and
OTA_CruiseBookRQ.
The OpenTravel organizational structure is divided into four work groups: Hospitality, Transport, Architecture
and Travel Integration and this structure is reflected in the message-level XML schema.
Each message-level XML schema references other XML schema that, in turn, reference others. These message-
level schema contain the declaration of the root element that appears as the primary node of any XML instance
document based on that XML schema. The content contained within that root node may be defined in the mes-
sage-level schema itself or in files it includes.
OpenTravel Industry Common Types Schema
Because the OpenTravel specification provides numerous XML schema for each industry, all schema that pertain
to a specific industry will naturally share common data types. The OpenTravel modularity model supports this
need by containing XML schema files intended for use throughout the set of XML schema for each industry.
For example, the OTA_AirBookRQ and the OTA_AirPriceRQ schema both need to accommodate information
related to an air itinerary. Rather than having each file have to define that content separately, the
OTA_AirCommonTypes schema file provides a single definition of that data for use throughout the OpenTravel
air schema. This single data definition is manifested as a complex type named AirItineraryType.
OpenTravel Common Types Schema
The OpenTravel specification provides a common types file called OTA_CommonTypes that contains data struc-
tures that are referenced throughout the specification and shared by each of the respective industries.
The data types contained in this file may be referenced from message-level files, function-specific files, and in-
dustry common files.
Keep in mind that any of these files can declare elements that reference complex types, simple types, and attrib-
ute groups in the OTA_CommonTypes file.
OpenTravel Simple Types Schema
The OTA_SimpleTypes XML schema serves as a module that contains simple types that are available for use
throughout the specification.
The design goal of this file is identical to that of the OTA_CommonTypes file in that it serves as a single contain-
er for global simple types.
These types can be used at any level of the schema hierarchy. Most of the simple data types contained within this
schema provide basic data structures that the other schema use to build larger collections of data.
31
© 2013, OpenTravel Alliance. All rights reserved.
OpenTravel Message Transport
Introduction
Historically, the primary work of OpenTravel has been to provide a data exchange specification for the travel
industry. As use of the specification increased, however, the implementer community began expressing a need
for OpenTravel to also provide guidance regarding how these schemas should be used within real-world software
applications.
The OpenTravel architecture work group responded to these requests by launching projects to provide guidance
about nonfunctional areas such as HTTP, SOAP, and WSDL. As is the case with the schemas, guidance docu-
mentation for these areas will be maintained over the long term to reflect changing needs and a continually
evolving standards and technology market.
While OpenTravel recognizes that these standards are developed and maintained by the W3C, it also recognizes
that it can help reduce efforts associated with interoperability in the travel industry by publishing implementa-
tion guidance documents that help travel companies implement web services in a consistent manner. The sec-
tions below provide guidance for using OpenTravel XML schemas in conjunction with the SOAP and HTTP mes-
saging protocols.
Definitions & Conventions
Each of the sections below provide guidelines regarding the use of a technology in conjunction with the Open-
Travel specification. Guidelines may be denoted by the symbol ‘§’. Since this document is recommended guid-
ance and not an enforceable requirement (from the perspective of OpenTravel), the guidelines herein make use
(primarily) of SHOULD nomenclature.
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT,"
"RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in IETF doc-
ument RFC 2119.
In other words, "MUST," "MUST NOT," "REQUIRED," "SHALL," and "SHALL NOT" identify protocol features
that are not optional.
Similarly, "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" identify statements
that require consideration with regard to the impact that inclusion or exclusion of the protocol feature will have
on the interoperability of the system.
State Maintenance
In general, OpenTravel messages were designed to support transactions that occur within a stateless environ-
ment. Within the messages, this is reflected by a tendency to include data in the response that was defined in the
request. With this design, message senders and recipients are not forced to “remember” data between message
sends.
As an example of this design philosophy, the image below depicts the OTA_AirAvailRQ and OTA_AirAvailRS as
they appear in an XML schema editor. For each message, the highlighted element OriginDestinationInformation
contains content that is similar across the request and response message.
Please note that a number of OpenTravel messages are intended for use within legacy environments that do
maintain state. As a result, those schemas do not include data elements in the response that were in the request.
32
© 2013, OpenTravel Alliance. All rights reserved.
SOAP Messaging
SOAP is a loosely coupled protocol for interaction between applications that may have been developed on differ-
ent platforms using different languages. SOAP uses XML for payload and a wide range of underlying protocols
for transport - one of them being HTTP.
Earlier proprietary protocols required client and server applications to be of the same breed, use a common pro-
tocol framework or at least run on the same platform. With the introduction of SOAP, this tight coupling be-
tween client and server applications was eliminated and applications could communicate across platform and
language barriers.
Many applications are already using SOAP for the interchange of OpenTravel documents, and more are in the
process of being developed. Until now there have not been any guidelines or specifications describing how
OpenTravel documents should be encapsulated and transported in SOAP messages. This has prevented many
existing applications from inter-operating, even when these applications conform to the SOAP and OpenTravel
specifications. This section aims to bridge that gap and acts as guide to software architects and developers who
want to create interoperable OpenTravel clients and services using SOAP.
Purpose
The main purpose of this section is to provide well-defined guidelines for creating and using OpenTravel services
over SOAP in a manner that ensures interoperability. The goal is that any party that develops OpenTravel-based
services in accordance with this section should be able to interoperate without having to implement any changes
in SOAP/OpenTravel message structure or at a protocol level. This section also attempts to outline the simplest
method of transmitting OpenTravel messages over SOAP. With simplicity comes ease of implementation and in
most cases also efficiency. OpenTravel recommendation of these guidelines will help to ensure wide distribution
amongst implementers within the travel industry.
The SOAP Transport Protocol
Microsoft started working on the SOAP specification as early as 1998, and a specification was first released in
late 1999. This specification used a sub-set of the then in-progress XML Schema specification. SOAP was initially
intended as a replacement for existing RPC protocols such as GIOP/IIOP, DCE/DCOM, RMI, and ONC, but has
also developed into a document exchange transport mechanism with similarities to EDI. SOAP was submitted to
W3C’s XML Protocol Working Group in 2000. SOAP was released as a “Note” from W3C in May 2000.
SOAP provides a simple and extensible vehicle for interchanging data and invoking remote services using XML,
as demonstrated by the skeleton SOAP structures in Figures 1, 2 and 3:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Routing, security or other control data. -->
</soap:Header>
<soap:Body>
<!-- RPC method call or document data. -->
</soap:Body>
</soap:Envelope>
Figure 1: Skeleton SOAP response
The only limitation to the content of the SOAP Body element is that it must be a valid XML document. This im-
plies that the content is a single XML element, which either represents a remote service/method or is the root
element of an XML document that is being exchanged.
The Header element is optional in all SOAP messages and is used to carry information apart from the actual en-
velope payload such as routing or security information.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
33
© 2013, OpenTravel Alliance. All rights reserved.
<soap:Header>
<!-- Routing, security or other control data. -->
</soap:Header>
<soap:Body>
<!-- RPC method response or document data. -->
</soap:Body>
</soap:Envelope>
Figure 2: Skeleton SOAP positive response
The same limitation with regard to the content of the SOAP Body element applies to positive SOAP response
messages.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Routing, security or other control data. -->
</soap:Header>
<soap:Fault>
<faultcode>soap:Client.AppError</faultcode>
<faultstring>Application Error</faultstring>
<detail>
<message>Something went wrong</message>
<errorcode>12345</errorcode>
</detail>
</soap:Fault>
</soap:Envelope>
Figure 3: Skeleton SOAP negative response
Negative response messages contain a Fault element in place of a Body element.
The Need for Interoperability
SOAP is already being widely used for transporting OpenTravel documents. However, due to the dual purpose of
SOAP (RPC vs. messaging) and SOAP’s flexibility with regards to structure, a whole range of SOAP structures
are being used to transport OpenTravel data.
Many travel companies expose OpenTravel or OpenTravel -like services using SOAP, with different implementa-
tion approaches:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<OTA_CancelRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2.001">
<POS>
<Source ISOCountry="US" ISOCurrency="NOK" PseudoCityCode="HUR">
<RequestorID ID="abc.123" URL="abcde..."/>
</Source>
</POS>
<UniqueID ID="DGNJ6012990-389" Type="14"/>
</OTA_CancelRQ>
</soap:Body>
</soap:Envelope>
Figure 4: SOAP messaging
34
© 2013, OpenTravel Alliance. All rights reserved.
Using SOAP messaging, the OpenTravel payload is the only and immediate child of the SOAP Body element.
This is the simplest and most efficient means of transporting OpenTravel messages over SOAP.
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<acme:otaServiceCancel xmlns:acme="http://www.acme-travel.com">
<OTA_CancelRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2.001">
<POS>
<Source ISOCountry="US" ISOCurrency="NOK" PseudoCityCode="HUR">
<RequestorID ID="abc.123" URL="abcde..."/>
</Source>
</POS>
<UniqueID ID="DGNJ6012990-389" Type="14"/>
</OTA_CancelRQ>
</acme:otaServiceCancel>
</soap:Body>
</soap:Envelope>
Figure 5: SOAP RPC
With SOAP RPC the immediate child of the SOAP Body element is an XML element that describes the method or
function that is being invoked, in this case “otaServiceCancel”. The namespace of this element is most often de-
fined by the service application (it is not the OpenTravel namespace).
Accept-Language: en
Content-Type: multipart/related; type="text/xml"; boundary="----…"
Content-Id: soap-envelope
Content-Length: 923
SOAPAction: OTA_CancelRQ
User-Agent: Acme SOAP Client
-----=Multipart_Boundary_1136385692441_3=----
Content-Type: text/xml
Content-Id: soap-envelope
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<acme:otaServiceCancel xmlns:acme="http://www.acme-travel.com">
<acme:payload location="cid:OTA_CancelRQ"/>
</acme:otaServiceCancel>
</soap:Body>
</soap:Envelope>
-----=Multipart_Boundary_1136385692441_3=----
Content-Type: text/xml; charset="UTF-8"
Content-Id: OTA_CancelRQ
<OTA_CancelRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2.001">
<POS>
<Source ISOCountry="US" ISOCurrency="NOK" PseudoCityCode="HUR">
<RequestorID ID="abc.123" URL="abcde..."/>
</Source>
</POS>
<UniqueID ID="DGNJ6012990-389" Type="14"/>
</OTA_CancelRQ>
Figure 6: SOAP RPC with attachment
All the above are taken from real-world use of SOAP for interchange of OpenTravel messages. There is nothing
inherently wrong with any of these methods; they all use SOAP to carry OpenTravel messages, but they are not
interchangeable.
35
© 2013, OpenTravel Alliance. All rights reserved.
The need for a well-defined specification in this area is obvious due to the increased use of OpenTravel messag-
es, an increasing number of SOAP-based OpenTravel services, and the variety of SOAP structures that can be
used to carry OpenTravel messages.
Guidelines for OpenTravel Documents & Messages
This section describes a set of guidelines for a uniform method of using SOAP for interchange of OpenTravel
messages. These guidelines do not, in any way, state that OpenTravel services or clients must use SOAP for
transport, nor must they conform to these guidelines. These guidelines can be used to maximize interoperability
with other SOAP-based OpenTravel clients and services. This section is not intended to contain contradiction of
or repetition of what is already stated as rules or guidelines in other third party specifications:
Specification
Location
SOAP 1.1 specification
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
SOAP 1.2 specification
http://www.w3.org/TR/soap12/
SOAP with attachments
http://www.w3.org/TR/2000/NOTE-SOAP-attachments-
20001211
WS-I basic profile
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-
16.html
WS-Security specification
http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wss
XML-Signature specification
http://www.w3.org/TR/xmldsig-core/
XML-Encryption specification
http://www.w3.org/TR/xmlenc-core/
WSDL 1.1 recommendation
http://www.w3.org/TR/wsdl
SOAP Version 1.1 and 1.2
SOAP version 1.1 was released as a “Note” from W3C in 2000. This specification had few changes from what was
submitted to W3C’s XML Protocol Working Group the same year. The main addition was a fixed namespace
(http://schemas.xmlsoap.org/soap/envelope/).
The main change in SOAP version 1.2, released as a W3C “Recommendation” in June 2003, was a change in the
namespace (now http://www.w3.org/2003/05/soap-envelope) and a change in how the SOAP Action value was
transmitted over HTTP.
Accept-Language: en
Content-Type: type="text/xml";
Content-Length: 194
SOAPAction: GetStockQuote
User-Agent: Acme SOAP Client
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getStockQuote Ticker="SUNW"/>
</soap:Body>
</soap:Envelope>
Figure 1: SOAP 1.1 HTTP Sample
36
© 2013, OpenTravel Alliance. All rights reserved.
Accept-Language: en
Content-Type: type="text/xml"; action="GetStockQuote";
Content-Length: 193
User-Agent: Acme SOAP Client
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<getStockQuote Ticker="SUNW"/>
</soap:Body>
</soap:Envelope>
.
.
.
Figure 2: SOAP 1.2 HTTP Sample
Most SOAP toolkits/stacks support both versions of SOAP. By using a standard development kit or SOAP stack
one ensures that an application will support both SOAP versions.
§ 1. OpenTravel implementers using the SOAP protocol MUST support either SOAP 1.1 or SOAP 1.2 for clients
and services.
§ 2. OpenTravel implementers using the SOAP protocol SHOULD support SOAP 1.1 and SOAP 1.2 for clients and
services.
SOAP Messaging and SOAP RPC
Differences between SOAP Messaging and SOAP RPC
The SOAP protocol can be used both for messaging (exchanging messages/documents) and for RPC (invoking
remote services). The structure of the SOAP Envelope, Header and Body elements are the same for both para-
digms, but the content of the SOAP Body element is different.
When using SOAP messaging for document exchange, the content of the SOAP Body element is a document or
message that is sent from one party to another. This document or message is the only content inside the SOAP
Body, and the root element of the document or message is the only immediate child element of the SOAP Body
(i.e., you cannot transmit more than one document inside a single SOAP Body element). The exchanged docu-
ment or message is often defined using an XML schema that is either agreed upon between the two SOAP parties
or defined by a standards body (such as OpenTravel).
When using SOAP RPC the content of the SOAP Body element describes a service invocation (a remote proce-
dure call). This description normally includes a procedure or function name and a set of parameters. The param-
eters can be one or more XML documents or messages, so it is possible to exchange documents and messages
using SOAP RPC. The structure of the SOAP Body contents is defined on a per-service basis, and is most often
described in a WSDL document that is made available by the SOAP RPC service.
WSDL Document/ Literal Binding
WSDL can be used to describe both RPC and document exchange services. For document exchange services, the
document/literal binding must be used (described in the W3C WSDL 1.1 specification sections 3.3 through 3.5):
<wsdl:definitions ...>
...
<wsdl:binding name="mySoapBinding" type="impl:SOAPClientInterface">
<!-- Use document style and not rpc. -->
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- Define OTA_Cancel operation using OpenTravel-defined messages. -->
37
© 2013, OpenTravel Alliance. All rights reserved.
<wsdl:operation name="OTA_Cancel">
<wsdlsoap:operation soapAction="OTA_Cancel"/>
<wsdl:input name="OTA_CancelRQ">
<wsdlsoap:body namespace="http://www.acme.com/ota" use="literal"/>
</wsdl:input>
<wsdl:output name="OTA_CancelRS">
<wsdlsoap:body namespace=" http://www.acme.com/ota " use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
.
.
.
Figure 3: WSDL Document/Literal Binding Example
SOAP Messaging Benefits
The main benefit of using SOAP messaging for exchange of OpenTravel messages is that the content of the SOAP
Body element is always a single OpenTravel message. This means a SOAP client can use the exact same message
structure for any OpenTravel service that uses SOAP messaging. If using SOAP RPC, each OpenTravel service
would define its own SOAP message structure (procedure name, etc.), and a client would have to use a different
message structure for each SOAP RPC service.
As an example, we can consider a SOAP client that wants to issue an OTA_AirLowFareSearchRQ request to a set
of OpenTravel services: A, B and C. If using SOAP messaging, the client could construct a single SOAP envelope
containing an OTA_AirLowFareSearchRQ and issue it to services A, B and C. If the services were using SOAP
RPC, the client would have to first determine the required SOAP RPC message structure for services A, B and C,
create one SOAP request for each service (containing the OTA_AirLowFareSearchRQ as a parameter) and issue
the request to each service.
SOAP Messaging vs. RPC Guidelines
The overhead of using RPC is obvious, and even more so when considering the similar complexity in handling
SOAP RPC response messages. But the main advantage to using SOAP messaging is ease of integration and in-
ter-operation.
§ 3. OpenTravel implementers SHOULD use SOAP messaging for transmitting OpenTravel documents between
a SOAP client and a SOAP service.
SOAP Action URI
SOAP Messaging and the SOAP Action URI
The SOAP Action is a URI that is transmitted with a SOAP Envelope, separate from the envelope’s XML content.
This URI is meant to carry the intent of the SOAP message. With SOAP messaging the SOAP operation (service
name) is not included in the SOAP message. The SOAP Action can be used to send an operation name from the
client to the service in cases where the operation is not implied by the type of document that is being sent.
SOAP Intermediaries
The SOAP Action URI can also be very valuable to SOAP intermediaries, such as a SOAP gateway, router or
proxy. Intermediaries can forward or otherwise handle a SOAP message based on its SOAP Action value, without
having to parse the SOAP Envelope.
38
© 2013, OpenTravel Alliance. All rights reserved.
Figure 1: SOAP Intermediary
Tasks carried out by such intermediaries include:
- Routing of SOAP requests routing based on SOAP Action value.
- XML Schema validation of SOAP request contents XML Schema is chosen from the SOAP Action.
- XML Security token processing, such as XML Signature validation and decryption of XML Encryption
elements.
SOAP Action URI Guidelines
In scenarios where there is no SOAP intermediary there is most often no need for a SOAP Action URI. The serv-
er application can process an incoming message purely based on the root tag of the document it receives.
§ 4. Services SHOULD NOT require a SOAP Action URI to communicate with the service.
In scenarios where SOAP intermediaries are used, a SOAP Action URI may be used for in-transit processing. A
SOAP server application may also choose to use the SOAP Action URI for internal routing (at an application lev-
el).
§ 5. Services and intermediaries that require a SOAP Action URI SHOULD use the OpenTravel request tag root
as the SOAP Action URI. For low fares search, the SOAP Action URI would be “OTA_AirLowFareSearchRQ”.
Some SOAP intermediaries may not allow an administrator to configure the SOAP Action URI. For this reason a
SOAP Client application should allow the SOAP Action URI to be configured per service:
§ 6. Clients SHOULD support any SOAP Action URI for transmitting any OpenTravel message to a Web service.
SOAP Envelope Content
The structure of the SOAP Envelope is well defined in the SOAP 1.1, SOAP 1.2 and WS-I basic profile specifica-
tions. WS-I basic profile section 4.1 contains a very detailed description of a properly defined SOAP Envelope.
This description does not add, remove or change any of the requirements in SOAP 1.1 or 1.2, but offers the reader
a better understanding of the SOAP Envelope structure and constraints than the SOAP documents.
§ 7. SOAP Envelope content SHOULD conform to the SOAP 1.1 and SOAP 1.2 specifications, as clarified in WS-I
basic profile section 4.1.
SOAP Header Content
The SOAP Header element is used to carry information that is logically separate from the SOAP payload (con-
tents of the SOAP Body element) but that are required for the SOAP message to reach its endpoint. Such infor-
mation includes:
39
© 2013, OpenTravel Alliance. All rights reserved.
- Security tokens
- Routing information
- Timestamps
This element is not intended to carry all or portions of a SOAP message’s payload.
§ 8. SOAP Header elements in SOAP request and response messages SHOULD conform to the SOAP 1.1 and
SOAP 1.2 specifications, as clarified in WS-I basic profile section 4.1.
§ 9. SOAP Header elements SHOULD NOT contain OpenTravel data.
SOAP Body Content
As SOAP messaging is recommended, the content of the SOAP Body element should be a single OpenTravel re-
quest or response message. The only immediate child element of the SOAP Body should be the root element of
an OpenTravel message.
§ 10. SOAP Body elements in SOAP request and response messages SHOULD conform to the SOAP 1.1 and
SOAP 1.2 specifications, as clarified in WS-I basic profile section 4.1.
§ 11. All content within the SOAP Body element SHOULD be in the OpenTravel namespace, with the exception of
XML-Encryption tokens that are inserted in-place of encrypted OpenTravel elements.
§ 12. The content within a SOAP Body element SHOULD be valid, well-formed XML that conforms to an Open-
Travel schema.
§ 13. The only immediate child element of the SOAP Body element SHOULD be the root element of a document
that is defined in an OpenTravel schema.
3.2.4.13 SOAP Attachments
SOAP attachments are used to carry information that is in addition to the message payload.
§ 14. SOAP clients SHOULD support SOAP Attachments.
§ 15. SOAP services SHOULD limit the use of SOAP Attachments to images, such as hotel and vehicle images.
SOAP Attachments
SOAP attachments are used to carry information that is in addition to the message payload.
§ 14. SOAP clients SHOULD support SOAP Attachments.
§ 15. SOAP services SHOULD limit the use of SOAP Attachments to images, such as hotel and vehicle images.
SOAP Fault vs. OpenTravel Error
SOAP 1.1 and 1.2 define the SOAP Fault element as a vehicle for transporting error information from a SOAP
service to a SOAP client. OpenTravel also defines elements for returning errors and warnings to a SOAP client.
While the SOAP Fault element is capable of indicating application-level errors, as well as errors that originate in
the SOAP stack, this document recommends that the SOAP Fault element be used only to communicate and
transport (SOAP stack) errors.
§ 16. OpenTravel SOAP services SHOULD use SOAP Fault for SOAP-level errors.
§ 17. OpenTravel SOAP services SHOULD use OpenTravel Errors for application-level errors.
§ 18. OpenTravel SOAP clients SHOULD support both SOAP Fault and OpenTravel Error handling.
§ 19. SOAP Fault response messages SHOULD conform to the SOAP 1.1 or SOAP 1.2 specifications, as clarified in
WS-I basic profile section 4.1.
40
© 2013, OpenTravel Alliance. All rights reserved.
Examples
Most of the following examples use the OTA_ReadRQ and OTA_ReadRS messages. The messages are relatively
small and thus suitable for short and readable examples.
OTA_ReadRQ - Correct
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ota:OTA_ReadRQ xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:POS>
<ota:Source ISOCountry="CA" ISOCurrency="CAD" PseudoCityCode="AERO">
<ota:RequestorID ID="APP.001" URL="http://www.acme.com"/>
</ota:Source>
</ota:POS>
<ota:UniqueID ID="105789143" Type="21"/>
</ota:OTA_ReadRQ>
</soap:Body>
</soap:Envelope>
Figure: Correct OTA_ReadRQ Message
This example shows a correctly formatted SOAP request containing an OTA_ReadRQ message. The
OTA_ReadRQ element is the only immediate child element of the SOAP Body element. This format allows the
request to be issued to any Web service that implements the OTA_ReadRQ message as a non-RPC service.
OTA_ReadRQ - Incorrect - Escaped XML
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<acme:otaReadService xmlns:acme="http://www.acme.com/ota" Request="&lt;ota:OTA_ReadRQ
xmlns:ota=&quot;http://www.opentravel.org/OTA/2003/05&quot;&gt;&lt;ota:POS&gt;&lt;ota:Sourc
e ISOCountry=&quot;CA&quot; ISOCurrency=&quot;CAD&quot;
PseudoCityCode=&quot;AERO&quot;&gt;&lt;ota:RequestorID ID=&quot;APP.001&quot;
URL=&quot;http://www.acme.com&quot;/&gt;&lt;/ota:Source&gt;&lt;/ota:POS&gt;&lt;ota:UniqueID
ID=&quot;105789143&quot; Type=&quot;21&quot;/&gt;&lt;/ota:OTA_ReadRQ&gt;"/>
</soap:Body>
</soap:Envelope>
Figure: Incorrect OTA_ReadRQ Message - Escaped XML
This is an RPC-type SOAP request containing a call to an “otaReadService” defined by one particular Web Ser-
vice. This OpenTravel request is serialized and passed to this service as a string. This SOAP message is tied to
this particular service and is not in accordance with the guidelines in this document.
41
© 2013, OpenTravel Alliance. All rights reserved.
OTA_ReadRQ - Incorrect - Wrapped in Other XML
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<acme:otaReadService xmlns:acme="http://www.acme.com/ota">
<ota:OTA_ReadRQ xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:POS>
<ota:Source ISOCountry="CA" ISOCurrency="CAD" PseudoCityCode="AERO">
<ota:RequestorID ID="APP.001" URL="http://www.acme.com"/>
</ota:Source>
</ota:POS>
<ota:UniqueID ID="105789143" Type="21"/>
</ota:OTA_ReadRQ>
</acme:otaReadService>
</soap:Body>
</soap:Envelope>
Figure : Incorrect OTA_ReadRQ Message - Wrapped in Other XML
This message is also an RPC-type SOAP request. Even though the OpenTravel request is not serialized it is still
tied to a particular service, thus not in accordance with the guidelines in this document.
OTA_ProfileReadRS - Successful, Correct
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ota:OTA_ProfileReadRS xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:Success/>
<ota:Profiles>
<ota:ProfileInfo>
<ota:UniqueID ID="111240578" Type="21"/>
...
</ota:ProfileInfo>
</ota:Profiles>
</ota:OTA_ProfileReadRS>
</soap:Body>
</soap:Envelope>
Figure: Correct OTA_ProfileReadRS Successful Response
The same guideline stating that the SOAP Body element should only contain a single OpenTravel message also
applies to SOAP response messages. This message is correctly formatted, as the immediate child element of the
SOAP Body is an OpenTravel response message root element.
42
© 2013, OpenTravel Alliance. All rights reserved.
OTA_ProfileReadRS - Unsuccessful, Correct (Application-Level Error)
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ota:OTA_ProfileReadRS xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:Errors>
<ota:Error Code="282" Status="NotProcessed" Type="10"/>
</ota:Errors>
</ota:OTA_ProfileReadRS>
</soap:Body>
</soap:Envelope>
Figure: Correct OTA_ProfileReadRS Unsuccessful Response (Application-Level Error)
This message carries an application-level error back to the client application. Application level errors should be
reported using OpenTravel error elements.
OTA_ProfileReadRS - Unsuccessful, Correct (SOAP-Level Error)
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:MustUnderstand</faultcode>
<faultstring>SOAP Action URI missing</faultstring>
<faultactor>http://www.acme.com/services/ota</faultactor>
<detail>...</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Figure: Correct OTA_ProfileReadRS Unsuccessful Response (SOAP-Level Error)
This response message carries a SOAP-level error back to the client. Such errors should not be generated by an
OpenTravel server application, but can be generated by an XML intermediary or the OpenTravel application’s
SOAP stack/API.
43
© 2013, OpenTravel Alliance. All rights reserved.
Sample SOAP Messaging WSDL for OpenTravel
<wsdl:definitions
targetNamespace="http://www.acme.com/ota"
xmlns:impl="http://www.acme.com/ota"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<!-- Import of request and response schemas. -->
<xsd:import schemaLocation="OTA_ReadRQ.xsd"/>
<xsd:import schemaLocation="OTA_ProfileReadRS.xsd"/>
<!-- No additional data types should be required. -->
<wsdl:types/>
<!-- Define request and response message. -->
<wsdl:message name="OTA_ReadRQ">
<wsdl:part name="OTA_ReadRQ" element="ota:OTA_ReadRQ"/>
</wsdl:message>
<wsdl:message name="OTA_ProfileReadRS">
<wsdl:part name="OTA_ProfileReadRS" element="ota:OTA_ProfileReadRS"/>
</wsdl:message>
<!-- Define SOAP interface. -->
<wsdl:portType name="SOAPClientInterface">
<wsdl:operation name="OTA_Read">
<wsdl:input message="impl:OTA_ReadRQ" name="OTA_ReadRQ"/>
<wsdl:output message="impl:OTA_ProfileReadRS" name="OTA_ProfileReadRS"/>
</wsdl:operation>
</wsdl:portType>
<!-- Define SOAP binding for SPM. -->
<wsdl:binding name="spmSoapBinding" type="impl:SOAPClientInterface">
<!-- Use document style and not rpc. -->
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- Define operation using defined messages. -->
<wsdl:operation name="OTA_Read">
<wsdlsoap:operation soapAction="ReadProfile"/>
<!-- Use 'literal' to include OTA XML as-is. -->
<wsdl:input name="OTA_ReadRQ">
<wsdlsoap:body namespace="http://localhost/services/spm/spm" use="literal"/>
</wsdl:input>
<wsdl:output name="OTA_ProfileReadRS">
<wsdlsoap:body namespace="http://localhost/services/spm/spm" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<!-- Define SOAP interface with previously declared binding. -->
<wsdl:service name="SOAPClientInterfaceService">
<wsdl:port binding="impl:spmSoapBinding" name="spm">
<wsdlsoap:address location="http://www.acme.com/services/ota"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Figure: Sample WSDL Definition for Simple OpenTravel Service
44
© 2013, OpenTravel Alliance. All rights reserved.
This outlines how an OpenTravel service can be described in a WSDL document. The only data-types used in this
document are types that are already defined in OpenTravel schemas. The <binding/> element declares the ser-
vice as using the document/literal style to pass OpenTravel-defined messages as-is between the OpenTravel cli-
ent and service.
45
© 2013, OpenTravel Alliance. All rights reserved.
SOAP with Attachments Sample
Accept-Language: en
Content-Type: multipart/related; type="text/xml"; boundary="----=Multipart_Boundary_=----"
Content-Id: soap-envelope
Content-Length: 8967
-----=Multipart_Boundary_=----
Content-Type: text/xml
Content-Id: soap-envelope
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<OTA_HotelAvailRS xmlns="http://www.opentravel.org/OTA/2003/05">
<Success/>
<RoomStays>
<RoomStay xmlns="http://www.opentravel.org/OTA/2003/05">
...
<BasicPropertyInfo BrandCode="DE" ChainCode="DE" ...>
<VendorMessages>
<VendorMessage>
<SubSection SubTitle="HotelImage">
<Paragraph>
<URL>cid:HotelPool.jpg</URL>
</Paragraph>
</SubSection>
</VendorMessage>
...
</VendorMessages>
...
</BasicPropertyInfo>
</RoomStay>
</RoomStays>
</OTA_HotelAvailRS>
</soap:Body>
</soap:Envelope>
-----=Multipart_Boundary_=----
Content-Type: image/jpeg
Content-Id: HotelPool.jpg
...binary image data goes here...
-----=Multipart_Boundary_=------
Figure: OpenTravel Message with Hotel Image Attachment
The above example shows how a binary attachment can be returned with an OpenTravel response message. The
SOAP Envelope containing the OpenTravel response is the main part of the response message. The OpenTravel
message references an attachment using the ‘cid:’ URL prefix.
46
© 2013, OpenTravel Alliance. All rights reserved.
WS-Security Token Sample
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:actor="acme-ota-proxy" xmlns:wsse="...">
<wsse:UsernameToken wsu:Id="morten" xmlns:wsu="...">
<wsse:Username>morten</wsse:Username>
<wsse:Nonce EncodingType="UTF-8">
7h9x9UYevqMgBUzT2CXAK2oVYYU2J9PeEG0ZQniz8Tk=
</wsse:Nonce>
<wsse:Password Type="wsse:PasswordDigest">
3gDnTTVAd19NqSVA0c9sl1mNJrM=
</wsse:Password>
<wsu:Created>2006-01-17T17:55:14Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<ota:OTA_ReadRQ xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:POS>
<ota:Source ISOCountry="CA" ISOCurrency="CAD" PseudoCityCode="AERO">
<ota:RequestorID ID="APP.001" URL="http://www.acme.com"/>
</ota:Source>
</ota:POS>
<ota:UniqueID ID="105789143" Type="21"/>
</ota:OTA_ReadRQ>
</soap:Body>
</soap:Envelope>
Figure: OpenTravel SOAP Message with WS-Security Token
This sample OpenTravel request contains a WS-Security username/password token. The SOAP Body contains
only the OpenTravel request payload, while the security token is placed in the SOAP Header. The security token
is typically processed by a SOAP proxy, such as an XML Security Gateway, while the SOAP Body content is pro-
cessed by an OpenTravel Web service. The security token and OpenTravel request are kept separate, which helps
disconnect the OpenTravel Web service from the security layer.
This example illustrates how standard WS-Security compliant implementations may be leveraged by OpenTravel
Message producers and consumers. As with all referenced specifications, the goal is to leverage these industry
standards. Please refer to the WS-Security specification for further details on this authentication method.
47
© 2013, OpenTravel Alliance. All rights reserved.
XML-Signature Sample
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:actor="acme-ota-proxy" xmlns:wsse="...">
<dsig:Signature Id="MortenJorgensen" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<dsig:XPath xmlns:ota="http://www.opentravel.org/OTA/2003/05">
ancestor-or-self::ota:UniqueID
</dsig:XPath>
</dsig:Transform>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>C33iD3LMNL0/4aSey+DdzH76Cng=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
nIYgIKl7D0pUKBGPhN36g/vnlNu38fRJ0uooKktbpFWsPQj8A75AXAJo4TYrssgrkJoWZOFnY8h0
d4PDAJcbgRjFusZYRhlQ3MWEMJ/9GFnLyglNTcveskWNweuUgyz56ARHHnb6MUvEzykMV4So6zaX
6I8I130T3/r0NaD0DLE=
</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:KeyName>CN=Morten Jorgensen,O=OpenJaw,...,C=IE</dsig:KeyName>
</dsig:KeyInfo>
</dsig:Signature>
</wsse:Security>
</soap:Header>
<soap:Body>
<ota:OTA_ReadRQ xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:POS>
<ota:Source ISOCountry="CA" ISOCurrency="CAD" PseudoCityCode="AERO">
<ota:RequestorID ID="APP.001" URL="http://www.acme.com"/>
</ota:Source>
</ota:POS>
Figure: Signed OpenTravel SOAP Message
This sample OpenTravel request has an XML Signature element, which contains a digital signature over the
OpenTravel payload. Again, the SOAP Body contains only the OpenTravel request payload, while the security
token is placed in the SOAP Header. The security token is typically processed by a SOAP proxy, such as an XML
Security Gateway, while the SOAP Body content is processed by an OpenTravel Web service. The security token
and OpenTravel request are kept separate, which helps disconnect the OpenTravel Web service from the security
layer. Please refer to the XML-Signature and WS-Security specifications for further details.
48
© 2013, OpenTravel Alliance. All rights reserved.
XML-Encryption Sample, Correct
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:actor="acme-ota-proxy" xmlns:wsse="...">
<enc:EncryptedKey xmlns:enc="..." Encoding="utf-8" MimeType="text/xml">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5">
<enc:KeySize>256</enc:KeySize>
</enc:EncryptionMethod>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:KeyName> CN=Morten Jorgensen,O=OpenJaw,...,C=IE</dsig:KeyName>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>
I6kwMqpERPpbYoKa2lc/7g4kOuT/ntbpkXbRTX0VQFs6NYOcGItuvpB9qrCe4XKb
FKsePNOMQmUQQjSzZvIfzhLDst01NZaHCVRZ8FBAGiAWTH06ZPZEDc10WObcy+Y6
hWJ4Gd0XpDTmaUc3pRei18iWZOYz9no6PjyfJDThIQI=
</enc:CipherValue>
</enc:CipherData>
<enc:CarriedKeyName>session-key</enc:CarriedKeyName>
</enc:EncryptedKey>
</wsse:Security>
</soap:Header>
<soap:Body>
<ota:OTA_ReadRQ xmlns:ota="http://www.opentravel.org/OTA/2003/05">
<ota:POS>
<ota:Source ISOCountry="CA" ISOCurrency="CAD" PseudoCityCode="AERO">
<ota:RequestorID ID="APP.001" URL="http://www.acme.com"/>
</ota:Source>
</ota:POS>
<enc:EncryptedData xmlns:enc="..." Encoding="utf-8" MimeType="text/xml"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc">
<enc:KeySize>256</enc:KeySize>
</enc:EncryptionMethod>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:KeyName>session-key</dsig:KeyName>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>
fcU3IOeBS/wPKxJgPimX/apgGMnfKjF/hYOceAVLz6avzEn97xV/ipBlMLDTilef
q4NJWQiwJyqWzXjCQFVEp+OTFav29m6NMc336psfZbpBXLXjNTGBtslVYZ0G2l4P
FKLFua4nljlr5ve8vxn/AA==
</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedData>
</ota:OTA_ReadRQ>
</soap:Body>
</soap:Envelope>
Figure: Encrypted OpenTravel Sample SOAP Message
XML-Encryption tokens are the only type of security token that is inserted in-place of the SOAP payload (in this
case an OpenTravel Request). XML-Encryption tokens are typically used when the message travels across one or
more SOAP intermediaries or is processed by multiple Web service that need access to only certain parts of the
request. Exchange of encrypted XML normally follows these steps:
A SOAP client typically creates the request as clear-text XML. The sensitive portions of the request are encrypted
either by the SOAP client itself or by a proxy that resides inside the local network of the SOAP client. The SOAP
49
© 2013, OpenTravel Alliance. All rights reserved.
request is encrypted using the public key of the Web service it is intended for. The SOAP request can then safely
travel across a public network.
The SOAP request is typically decrypted by an XML Security Gateway before it is forwarded to the Web service.
The XML Security Gateway decrypts the SOAP request using the public key of the Web service.
The key point to note is that both the client and service handle OpenTravel messages in clear text, while the en-
cryption proxy and security gateway handle the encryption and decryption processes. This allows the client and
server to be implemented as if SOAP messages are transmitted in clear text.
Figure: XML Encryption Scenario
Please refer to the XML-Encryption specification for further details.
50
© 2013, OpenTravel Alliance. All rights reserved.
HTTP Messaging
Background
2001C OpenTravel Infrastructure Guidelines
The 2001C OpenTravel Infrastructure guidelines were added to the OpenTravel specifications in the 2001C re-
lease. These guidelines included design goals, XML best practices, the concept of using flexible request/response
message pairs, and the use of ebXML as a transport protocol for passing these messages. The specification of the
transport protocol was not formally part of the OpenTravel specification because OpenTravel members wished
to maintain flexibility with regard to which transport protocol they used.
Design Goals of OpenTravel (2001C)
In 2001, the Design Goals were stated as follows:
OpenTravel's basic goal is to design industry specifications capable of exploiting the communications systems
that are available with Internet connectivity. To achieve these goals, OpenTravel has designed specifications to
meet the following criteria:
- Openness- OpenTravel specifications are publicly available to all organizations seeking to develop new
or enhanced systems. Membership to OpenTravel is open to all organizations interested in developing
these specifications.
- Flexibility- OpenTravel specifications provides travel service providers with the flexibility they need to
develop, test and deploy new services. The specifications outline the minimum necessary functionality to
provide reliable interactions between customers and the systems owned and maintained by the compa-
nies serving them.
- Platform Independence- OpenTravel has developed this specification to work with any equipment or
software that can support the common standards used in the specification.
- Security- OpenTravel places great importance on the need to protect information from unauthorized ac-
cess and the need to give the customer control over the creation, update and exchange of data with other
parties.
- Extensibility- OpenTravel plans to add more services and functionality to this specification in a way that
minimizes incompatibility for those implementing this or other early versions. OpenTravel work groups
that develop the specifications do so with future transitions in mind.
- International scope- The initial specification was written in English; however, OpenTravel intends to ex-
tend later versions to provide representation in character sets supporting the Unicode standard. When
possible, OpenTravel has designed data elements to meet as many global elements as possible.
The Need for Interoperability
Emerging Trends
Since 2001, many new members have joined OpenTravel and want to know how to build systems that interoper-
ate with other vendors who have implemented OpenTravel messages. Within the travel industry, many more
integrators and intermediaries have emerged that wish to work with many partners. Decreasingly, the emphasis
is on enabling implementation of interactions between individual pairs of trading partners and increasingly on
creating services that interoperate with all interested trading partners.
Furthermore, recent OpenTravel message registrations have indicated that a simple transport protocol based on
an HTTP POST is increasingly popular.
These two trends suggest that a new specification is appropriate. This section describes this specification. It pro-
vides the guidance necessary to create interoperable applications based on a reference transport protocol.
51
© 2013, OpenTravel Alliance. All rights reserved.
It should not be construed that companies are any less OpenTravel conformant if they choose a different
transport protocol. This specification serves simply as guidance for companies wishing to make OpenTravel con-
formant applications that are highly interoperable.
New Design Goals
This HTTP transport protocol reference section addresses the following design goals in response to emerging
trends:
- Interoperable- Companies developing OpenTravel conformant systems should have sufficient guidance
to build systems which are highly interoperable with systems built by other companies using the same
OpenTravel messages for the same use cases.
- Simple- To be able to reach the most partners, operating from the most platforms, the protocol would do
well to be as simple as possible. This also reduces the hurdles for new members to implement Open-
Travel messages in their systems.
- Optimal Performance- The OpenTravel HTTP transport protocol should not impede performance by
burdening the processing with unnecessary overhead.
- Readily Accepted- The OpenTravel HTTP transport protocol should reflect what member companies are
already doing, thus assuring broad acceptance of the specification.
The following additional design goal is desirable, but is not directly addressed by this document:
- Certifiable- Companies should have some means whereby they can certify (for their own benefit) that
they have done what it takes to give their system a good chance of inter-operating with other companies’
systems.
Requirements for Interoperability
True interoperability is a lofty goal. A reference transport specification is necessary but not sufficient to achieve
it. The following are identified as important to achieving true interoperability:
- Standard Usage Profiles- OpenTravel messages are very flexible. However, if a set of systems are to be
interoperable with each other, they must use the selected OpenTravel messages in the same way for a
specific use case. OpenTravel plans to support the definition by member companies of Usage Profiles as
examples of OpenTravel messages, restricted to support a specific use case. Interoperability will require
that a set of Usage Profiles emerge that are generally accepted.
- Standard Transport Protocol- This document describes the OpenTravel Reference Transport Protocol.
For purposes of interoperability, it may serve as the standard.
- Standard Software Validation Suite- To have any confidence that a system will interoperate with other
systems, it must be exercised by a test suite to certify its features comply with the standards. The pro-
duction of software is currently beyond the scope of efforts sponsored by OpenTravel.
OpenTravel Transport Protocol Reference: HTTP
Philosophy of Interoperability
For maximum interoperability, your system SHOULD be liberal in what it accepts and strict in what it emits.
Simple HTTP POST vs. ebXML
The prior recommendations regarding ebXML are still available for companies wishing to implement that
transport protocol. However, OpenTravel acknowledges that adoption of ebXML among OpenTravel member
companies has been limited and that the following alternate protocol based on a simple HTTP POST represents
a simpler method to create interoperable systems.
Other transport protocol references may be specified in future OpenTravel releases. Such specifications may in-
clude (but are not limited to) SOAP (Simple Object Access Protocol).
52
© 2013, OpenTravel Alliance. All rights reserved.
Standard HTTP
Nothing in this specification should be understood to override or alter the standard definition of the HTTP pro-
tocol. The HTTP/1.0 and HTTP/1.1 versions of the HTTP protocol are described in the following documents:
HTTP/1.0 http://www.ietf.org/rfc/rfc1945.txt
HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt
However, the design of HTTP accommodates extensions through the use of custom headers. Custom headers
that are defined for OpenTravel transactions are described below.
53
© 2013, OpenTravel Alliance. All rights reserved.
HTTP Message Content
The OpenTravel transport protocol reference is based on a simple HTTP POST transaction. An HTTP POST
transaction allows for an arbitrarily large amount of “content” to be sent with both the request and with the re-
sponse. An OpenTravel request message is sent as the “content” in an HTTP POST request, and an OpenTravel
Response message is received in response.
HTTP Message Headers
In addition to the “content”, an HTTP message (request or response) also carries HTTP “headers.” The goal of
the following description of headers is to describe maximum simplicity and interoperability using HTTP. If a
system developer uses any standard HTTP-handling libraries or components, these details should be handled
automatically for them.
Both clients and servers MUST support HTTP/1.0. They MAY support HTTP/1.1, but if they do, they MUST sup-
port the client/server negotiation that allows the server to downgrade to HTTP/1.0 if the client cannot support
HTTP/1.1.
Different headers are allowed (or required) based on whether referring to the client (requestor) or server (re-
sponder) and whether using HTTP/1.0 or HTTP/1.1.
The only HTTP header REQUIRED for both request and response is the “Content-length” header. This allows
systems that implement the HTTP protocol themselves to be written simply. If HTTP/1.1 is used, the request
requires the “Host” header (a requirement of HTTP/1.1 itself). Other headers may be useful, but they are not re-
quired, and they may be safely ignored.
Header
Description
Example
Content-length
[REQUIRED] Tells how many bytes are in the “content”
(after the “headers”)
Content-length: 1558
Host
[REQUIRED for HTTP/1.1 Client according to HTTP/1.1
spec] This allows a server which is hosting multiple vir-
tual domains to know which domain the request was for.
If the server is not hosting multiple virtual domains, the
server MAY ignore this header.
Host: www.travelco.com
Connection
[OPTIONAL] Systems SHOULD utilize this header, but
they MUST be robust when communicating with another
server that does not recognize it. Using “Close” means
that the network socket will be closed after the exchange
of a single message (headers and content). “Keep-alive”
means that the network socket will be kept open for a
short time in case additional transactions are to be sent
on the same socket. “Close” is the default for HTTP/1.0,
and “Keep-alive” is the default for HTTP/1.1.
Connection: Close
Connection: Keep-alive
Accept-charset
[OPTIONAL] This tells a server what character sets the
client can handle. The server MAY ignore this if it will
only be responding with ASCII text. However, if it might
be responding with any non-ASCII text, it MUST encode
the data in accordance with one of the acceptable charac-
ter sets. “utf-8” is the preferred character set because
XML is specified to support Unicode, and “utf-8” is wide-
ly supported (and is ASCII-compatible). If the header is
supplied by the client, it MUST include “utf-8”. If the
header is not supplied, the server should assume “utf-8”.
In this way, both client and server should support “utf-8”
and the content in both request and response can be un-
Accept-charset: utf-8
54
© 2013, OpenTravel Alliance. All rights reserved.
Header
Description
Example
derstood to be “utf-8”.
Accept
[OPTIONAL] This tells a server what Content-types the
client can handle. The server SHOULD ignore this, be-
cause it is going to respond with an XML OpenTravel
response message regardless of what the client says he
can accept. The client MAY produce this header, but if so,
it SHOULD include at least one of the “xml” content
types.
Accept: text/xml
Accept: application/xml
Accept: application/xhtml+xml
Accept: text/html, text/plain
Accept-language
[OPTIONAL] This tells a server what languages the client
can handle.
Accept-language: en-us, en
Accept-encoding
[OPTIONAL] This tells a server whether the response
content can be compressed or not. Clients and servers
SHOULD implement a compressed encoding, but they
MUST support the standard HTTP negotiation that al-
lows them to interoperate with systems that do not im-
plement it.
Accept-encoding: gzip, deflate
[other]
[OPTIONAL] Clients and servers MAY provide other
headers and they MAY be ignored by the other system.
n/a
OpenTravel Custom Header: OTA-Echo-Token
For performance reasons, in order to accommodate massive exchanges of OpenTravel messages between two
systems in a high-volume B2B relationship, an optional HTTP Header, “OTA-Echo-Token”, may be used.
Without any extension to the HTTP protocol, the requesting system would send a request with a Keep-Alive
header and wait for a response. Each request would have to wait for a response. This is not high enough perfor-
mance for these applications.
When the “OTA-Echo-Token” header is used, the token value MUST be unique to that message and not shared
by any other message sent by that system. The sending system does not necessarily expect an immediate re-
sponse, but it does expect that whenever the response message is received, it will be accompanied by the same
token value in an “OTA-Echo-Token” header.
Using the “OTA-Echo-Token”, it is possible to multiplex several OpenTravel message transactions asynchro-
nously over the same TCP/IP connection. The token value correlates the request and the response.
Header
Description
Example
OTA-Echo-Token
[OPTIONAL] A token sent with a request that is ex-
pected to be echoed in a response. This is a string token
with a maximum size of 128 characters.
OTA-Echo-Token: 8335013
OTA-Echo-Token: A154/125/001
A requesting system that uses this header may only be attached to a responding system that uses the header, or
it will not receive the information necessary for it to function. A responding system that understands this header
SHOULD be able to reply synchronously to clients that do not use the header.
Encryption
- Encrypted communication between systems is accomplished with SSL (i.e., HTTPS).
- If encryption is required, a system MUST support HTTPS.
55
© 2013, OpenTravel Alliance. All rights reserved.
- Systems MAY communicate via unencrypted HTTP for transactions that do not need to be secure. HTTP
is also useful for transactions that are executed across a VPN or other networking channel that is already
secure for other reasons.
Authentication
- Authentication of a client (requestor) to a server (responder) is achieved via HTTP Basic Authentication.
- Authentication of a server (responder) to a client (requestor) is achieved via SSL.
- If authentication is required, a system MUST support HTTP basic authentication.
- Systems MAY communicate without authentication for transactions that do not require it.
Other Features: Logging
Organizations offering OpenTravel transactions MAY provide logging capability, regardless of the type of trans-
action in the business message (e.g., travel verbs, infrastructure verbs), and SHOULD provide logging capability
for all transactions that involve implicit or explicit contracts or promises to pay. Trading partners MAY exchange
event logs to provide audit trails.
56
© 2013, OpenTravel Alliance. All rights reserved.
GENERIC MESSAGES
Messages Overview
Unlike OpenTravel messages that are specific to a particular travel sub-domain (e.g., Air) other messages are
generally applicable and may be used more broadly than in one domain-specific service.
This section briefly describes the generic messages that can be used across multiple travel sub-domains.
There are several OpenTravel Generic Messages that provide a wide range of functionality, including:
- Payment validation and authorization (including bank and credit card)
- Reservation cancellations (full and partial)
- Customer profile deletions
- Sending file attachments for storage and processing by a receiving system
- Sending inventory and rates notifications
- Testing your application connectivity
- Purchasing gift certificates and other merchandise
- Retrieving reservations (by booking id, by passenger name, etc.)
- Requesting information in a free text type of response using a terminal message input
Messages List
- OTA_AuthorizationRQ/RS
- OTA_CancelRQ/RS
- OTA_DeleteRQ/RS
- OTA_ErrorRQ/RS
- OTA_FileAttachmentNotifRQ/RS
- OTA_NotifReportRQ/RS
- OTA_PingRQ/RS
- OTA_PurchaseItemRQ/RS
- OTA_ReadRQ/ OTA_ResRetrieveRS
- OTA_ScreenTextRQ/RS
57
© 2013, OpenTravel Alliance. All rights reserved.
OTA_AuthorizationRQ/RS
Message Pair Overview
The OpenTravel Authorization message pair verifies and validates a traveler based on information for a bank
account, credit card, or driver’s license. Each of these can be validated with or without an address.
The Authorization message could be used in any of the following circumstances:
- By a travel agent verifying that a customer bank account and/or credit card is valid for payment
- By a travel agent verifying that a customer bank account is valid for payment and their identification is
valid
- By an online travel website verifying that the customer credit card is valid and can be used as a form of
payment for the amount requested (and that the billing address for the account is accurate)
- By a travel agent verifying that the customer bank account is valid for payment on behalf of another
company or party
- By an online travel website to send multiple (bundled) booking authorizations' in a single request
When bundling multiple authorizations in a single request, each Authorizations element in the response must be
inspected to determine the result.
OTA_CancelRQ/RS
Message Pair Overview
The OpenTravel Cancel message pair is used for canceling a previously made (booked) reservation. This message
may be used to cancel the entire reservation or to cancel specific segments (portions) of the reservation.
A reservation ID (PNR locator, confirmation number, etc) is sent to specify which reservation should be can-
celed. Additionally, a supplier may require that verification information, such as customer name, credit card
number, and/or phone number, be sent in order to verify that the correct reservation is being canceled.
When only specific segments in the reservation are to be canceled, either a travel segment type (e.g. air, hotel,
cruise) or a segment number(s) is sent to indicate which segment(s) should be canceled.
The use of the OPTIONAL <POS> element allows an implementation to determine whether the remote user has
permission to cancel the reservation.
In the Cancel Request one of the following actions must be specified:
- Initiateindicates the initial request to cancel a reservation.
- Ignoreindicates a rollback of the request to cancel, leaving the reservation intact.
- Confirmindicates a request to complete the cancellation.
The Cancel Response will return one of the following statuses:
- Pendingindicates the initial request to cancel a reservation is pending confirmation to complete the
cancel action. Cancel rules may have been returned in the response.
- Ignoredindicates the request to cancel was rolled back, leaving the reservation intact.
- Cancelledindicates the cancellation is complete. A cancellation ID may be returned along with the re-
sponse.
The Cancel messages also provide the option for a two-step process and individual business rules that may de-
termine how a system processes the initial cancel request. If there are no penalties involved in the cancellation,
58
© 2013, OpenTravel Alliance. All rights reserved.
the cancel transaction can take place and the response returns the cancellation number along with the status
that the reservation has been canceled.
If the processing system determines that a cancellation policy has been invoked, it may choose to send back the
OTA_CancelRS with the Status="Pending", accompanied by a collection of cancellation rules, allowing the orig-
inating party to determine if the cancellation should proceed. The originating party would then resend the
OTA_CancelRQ.
A CancelType="Ignore" would expect a response with the Status "Ignored", thus ending the message conversa-
tion with no action being taken to cancel the reservation.
A CancelType="Commit" indicates a definitive instruction to process the cancellation. This message would ex-
pect the response of Status="Cancelled", along with the return of a Cancellation ID, which would complete the
cancellation process. The CancelRQ is the same message in each case, with the CancelType attribute indicating
the action to be taken on the request.
OTA_DeleteRQ/RS
Message Pair Overview
The OpenTravel Delete message pair uses an “action” attribute to define an operation that identifies an existing
record, and removes the entire record from the database. The use of the Delete action depends upon the busi-
ness rules of an organization. Alternative strategies, such as mapping a duplicate record to another by use of the
UniqueID, may be considered.
The requester MAY also verify the record before deleting it to ensure the correct record has been identified prior
to deleting it. In this case, the use of the Instance attribute may be useful in determining whether the record has
been updated more recently than the information that is intended to be deleted. That choice, again, would be
dictated by good business practices.
Steps in the Delete operation may include:
- Requester submits a Read request to view the record
- Responder returns the record for the requester to view
- Requester submits a Delete request
- Responder removes the record and returns an acknowledgment
The use of the OPTIONAL <POS> element allows an implementation to determine whether the remote user has
permission to delete the object being read.
OTA_ErrorRS
Message Pair Overview
In general, a system message request can fail in a number of common ways. For example the API key or user
name authentication may be invalid. The location or product being accessed may not belong to the operator
making the request and so on. Where appropriate, the standard OTA error response can be used.
The OpenTravel Error Response message is designed to accommodate errors that result from the parser, or from
validation, before reaching the server. The set of errors that can use this error is constrained by its limited struc-
ture, to provide structural stability. This message can be used when an OpenTravel message is not processed,
which may occur during a failed authentication, a failed xml parsing , or if a required field is missing and will be
wrapped by the message type sent.
The ErrorCode types shown below in italics are currently supported by OpenTravel, while the others are re-
served by the OpenTravel Specification but not implemented:
1. An unknown error.
59
© 2013, OpenTravel Alliance. All rights reserved.
2. The target business system has no implementation for the intended request.
3. The XML message has passed a low-level validation check, but that the business rules for the request
message were not met.
4. The message failed authentication.
5. The security credentials in the message have expired.
6. The message failed authorization.
7. A request was sent within a message exchange that does not align to the message.
8. The target business system does not support the intended transaction-oriented operation.
9. The type of authentication requested is not recognized.
10. An element or attribute that is required in by the schema (or required by agreement between trading
partners) is missing from the message.
OTA_FileAttachmentNotifRQ/RS
Message Pair Overview
The OpenTravel File Attachment Notification message pair enables a sending system to physically transfer en-
coded binary files to a receiving system that will store or process them.
The request message and the encoded files are transferred together in a single encoded entity, with the request
message being the first item retrieved by the receiving system. The receiving system uses the request message as
a table of contents with the descriptive information it needs to decode and store the files.
The response message acknowledges the received files and returns any warnings or errors as needed.
OTA_NotifReportRQ/RS
Message Pair Overview
The OpenTravel Notification Report message pair sends a report on whether asynchronous database updates
have been processed successfully or not. This message pair currently supports hotel and vehicle but may be ex-
tended in the future to accommodate other travel sector database reports.
The responses to the database update (e.g., OTA_HotelAvailNotifRS, OTA_HotelRateAmountNotifRS or
OTA_VehLocDetailsNotifRS) are only used to acknowledge the fact that the message has been received (because
the completion of the update in the application might take a few minutes). Moreover, in case of error, those
schema do not provide the ability to point out and give details on the part that failed and this scenario is when
this message pair is used.
The business flow for hotel availability and rate amount database updates is as follows:
1. A hotel provider sends a OTA_HotelAvailNotifRQ to a booking source.
2. The booking source acknowledge the fact that the message has been received (but not yet processed) by
replying with the OTA_HotelAvailNotifRS.
3. The booking source system process the database update.
4. Once the database update is completed the booking source system may need to inform the hotel provid-
er that updates were successful or not.
5. The booking source builds an OTA_NotifReportRQ message and sends it to the Hotel Provider.
6. The Hotel provider acknowledges it with an OTA_NotifReportRS message.
60
© 2013, OpenTravel Alliance. All rights reserved.
The business flow for vehicle location database updates is as follows:
1. A vehicle provider sends a OTA_VehLocDetailsNotifRQ to a recipient (e.g. a trading partner system.)
2. The recipient acknowledges the fact that the message has been received (but not yet processed) by reply-
ing with the OTA_VehLocDetailsNotifRS.
3. The recipient source system process the database update.
4. Once the database update is completed the recipient source system may need to inform the vehicle pro-
vider that updates were successful or not.
5. The recipient source builds an OTA_NotifReportRQ message and sends it to the vehicle provider.
6. The vehicle provider acknowledges it with an OTA_NotifReportRS message.
OTA_PingRQ/RS
Message Pair Overview
The OpenTravel Ping message pair are used to test application connectivity by sending some specific text and
determining if the receiving application is able to echo back that same text. The free-text data that is passed in
the request is expected to be echoed back in the response message.
OTA_PurchaseItemRQ/RS
Message Pair Overview
The OpenTravel Purchase Item message pair provides functionality for electronic purchases of non-inventory
items (e.g. gift certificates for a hotel, drink tickets on an airline, etc.) The message pair supports the ordering
process with detailed product, recipient, purchaser and payment information.
61
© 2013, OpenTravel Alliance. All rights reserved.
Key to this message pair are the OpenTravel OrdersType and Product complex elements defined in
OTA_CommonTypes.xsd. The OrdersType complex element contains the details of one or more repeating or-
der(s) as shown in the diagram below:
62
© 2013, OpenTravel Alliance. All rights reserved.
The repeating Product complex element contains the details of one or more products that are associated with the
order:
63
© 2013, OpenTravel Alliance. All rights reserved.
OTA_ReadRQ/OTA_ResRetrieveRS
Message Pair Overview
The OpenTravel Read infrastructure action defines an operation that opens an existing record and transmits
information contained in that record. The Read operation enables the user to identify a particular record and
retrieve its entire contents, to request a reservation when the booking id number is not known, to request a list
of reservations for a traveler, and to request a list of travelers that meet specified criteria.
In the Read request, it can be specified whether the reservation itself should be returned if an exact match is
found or if a list of reservations should be always be returned.
The basic operation has the following steps:
- Requester queries the database where the record resides by sending a Read request message with the
record's unique identifier or with information such as traveler name, date of travel, loyalty number
and/or other specified criteria.
- Responder returns the record or a list of reservations to the requester.
The response to the OTA_ReadRQ will vary based on the type of record(s) requested and you and your trading
partners' system capabilities. The following are examples of the type of records requested and the possible mes-
sage response:
Possible Response Messages
OTA_AirBookRS
OTA_ResRetrieveRS
OTA_ResRetrieveRS
OTA_GolfCourseResRS
OTA_ResRetrieveRS
OTA_ResRetrieveRS
OTA_HotelResRS
OTA_ResRetrieveRS
OTA_InsuranceBookRS
OTA_LoyaltyAccountRS
OTA_PkgBookRS
OTA_ResRetrieveRS
OTA_ProfileReadRS
OTA_ResRetrieveRS
If an exact match of the reservation is not found or a list is requested, the OTA_ResRetrieveRS message is re-
turned with a list of reservations with enough additional information to help the requester determine which res-
64
© 2013, OpenTravel Alliance. All rights reserved.
ervation they wish to see. The requester may then send another Read request with the reservation identifier to
retrieve a specific reservation.
OTA_ReviewsNotifRQ/RS
Message Pair Overview
The OpenTravel Reviews Notif message set is a push message used to push reviews based on specified criteria.
Reviews are evaluations that are completed by guests after they use a product or service. The receiving system
responds with an acknowledgement that the message was successfully received, or includes warnings from
business processing rules or errors if the request did not succeed. This message is currently designed to handle
hotel reviews, but can be easily updated to handle reviews from other travel sectors when needed.
OTA_ReviewsRQ/RS
Message Pair Overview
The OpenTravel Reviews message set is a pull message used to request reviews that may be filtered based on
criteria that is identified in the message. Reviews are evaluations that are completed by guests after they use a
product or service. The response is returned containing the reviews that match the specified criteria. This
message is currently designed to handle hotel reviews, but can be easily updated to handle reviews from other
travel sectors when needed.
OTA_ScreenTextRQ/RS
Message Pair Overview
The OpenTravel Screen Text message pair is used to request information in a free text type of response using a
terminal message input. It allows users who do not have fully developed XML capabilities to send and receive
XML messages and/or to request information for which there is no OpenTravel message functionality devel-
oped.
65
© 2013, OpenTravel Alliance. All rights reserved.
AIR MESSAGES
Messages Overview
The OpenTravel Air Messages provide a wide range of functionality, including:
- Requesting flight availability for a city pair on a specific date for a specific number and type of passen-
gers (optionally constrained by availability for a specific airline, flight or booking class on a flight, all for
a specific date)
- Booking (making a reservation) for a specific itinerary for one or more identified passengers (including
optional pricing information) while allowing the booking class availability and pricing to be rechecked as
part of the booking process
- Flight check in from a self-service channel (kiosks, web and mobile)
- Requesting ticket fulfillment
- Displaying booking files on a queue
- Requesting information on fares between city pairs for a particular date or date range with no Inventory
check for available seats
- Requesting updated information on the operation of a specific airline flight
- Requesting flight leg and codeshare information for a specific flight on a specific date between a city pair
- Requesting lowest fare priced itinerary options for flights between specific city pairs on certain dates for
specific numbers and types of passengers
- Requesting pricing information for specific flights on certain dates for a specific number and type of pas-
sengers (including optional information such as fare restriction preferences and negotiated fare contract
codes)
- Requesting text rules for a specific fare basis code for an airline and city pair on a specific date (includ-
ing optional information such as negotiated fare contract codes)
- Viewing airline flight schedules
- Displaying which seats are available for a given flight, as well as their location within the aircraft
- Modifying an existing booking file (reservation)
Messages List
- OTA_AirAvailRQ/RS
- OTA_AirBaggageRQ/RS
- OTA_AirBookRQ/RS
- OTA_AirCheckInRQ/RS
- OTA_AirDemandTicketRQ/RS
- OTA_AirDisplayQueueRQ/RS
- OTA_AirFareDisplayRQ/RS
- OTA_AirFlifoRQ/RS
- OTA_AirDetailsRQ/RS
- OTA_AirLowFareSearchRQ/RS
- OTA_AirPriceRQ/RS
66
© 2013, OpenTravel Alliance. All rights reserved.
- OTA_AirRulesRQ/RS
- OTA_AirSchedulesRQ/RS
- OTA_AirSeatMapRQ/RS
- OTA_AirBookModifyRQ/OTA_AirBookRS
- OTA_AirGetOfferRQ/RS
67
© 2013, OpenTravel Alliance. All rights reserved.
OTA_AirAvailRQ/RS
Message Pair Overview
The OpenTravel Air Availability message pair contains the structure and elements of requests and responses for
airline flight availability and point of sale information. The Air Availability request message requests flight avail-
ability for a city pair on a specific date for a specific number and type of passengers.
The request can also be narrowed to request availability for a specific airline, flight or booking class on a flight,
all for a specific date. Optional request information can include:
- Time / Time Window
- Connecting cities
- Client Preferences (airlines, cabin, flight types etc.)
The Air Availability response message contains flight availability for a city pair on a specific date. A set of origin
and destination options is returned, each of which contains one or more (connecting) flights that serve the city
pair. For each flight the following information is returned:
- Origin and destination airports
- Departure and arrival date/times
- Booking Class availability
- Equipment
- Meal Information
- Codeshare information
OTA_AirBaggageRQ/RS
Message Pair Overview
The OpenTravel Air Baggage message pair provides baggage pricing, allowance and list and/ or catalog function-
ality:
- Baggage Pricing
- Baggage Allowance
- Baggage List or Catalog with Pricing
Requested baggage operations may be based on a broad variety of criteria, including:
Specific request type (Baggage Allowance, Baggage Charge, Baggage Allowance and Charge and Baggage List)
- A specified airline supplier
- A specified company (associated with the traveler)
- A specific flight
- An air reservation (PNR)
- A traveler type
- Traveler loyalty benefits
- A fare group (including private and negotiated fares)
68
© 2013, OpenTravel Alliance. All rights reserved.
- An origin/ destination pair
- An associated offer
- A service family (product group and subgroup)
- Specific baggage information, including checked in indicator, quantity of pieces (checked bag and carry
on), weight, dimensions, special item code & description, and excess baggage occurrences.
Returned information includes:
- Allowance and Charge Information
- Baggage allowance and charge by origin and destination:
- Indicator if the baggage allowance may be subject to air supplier merchandising offers
- Baggage allowance details, including weight, dimensions, special item codes & descriptions, service fam-
ily and per item pricing (including currency type, amount, taxes, exchange rate details, redemption cur-
rency, pricing rules and pricing qualifiers)
- Booking and upgrade instructions
- Associated loyalty program that influenced the baggage allowance and/or pricing
- Marketing airline
- Service or bag specific fee calculation information or warnings
- Ticket box
- Airline merchandising offers that apply to baggage allowance and/or charges
- The total baggage price for the entire trip (including all passengers)
- Baggage List or Priced Catalog by origin and destination:
- Marketing airline
- Baggage detail, including maximum pieces, EMD type value, allowance method, service location, and
service date)
- Airline or ATPCO service family with pricing and booking instructions and booking instructions, pricing,
ticket box and offers at the product subgroup level
OTA_AirBookRQ/RS
Message Pair Overview
The OpenTravel Air Book message pairs books a specific itinerary for one or more identified passengers. The
messages contain optional pricing information, allowing the booking class availability and pricing to be re-
checked as part of the booking process.
- Optional request information can include:
- Seat and meal requests
- Special Service Requests (SSR), Other Service Information (OSI), Remarks
- Fulfillment informationpayment, delivery details, type of ticket desired
If the booking was successful, the Air Book response message contains the itinerary (including the directional
indicator, status of the booking, and number of passengers), passenger and pricing information sent in the re-
quest, along with a booking reference number (PNR Locator) and ticketing information.
OTA_AirCheckInRQ/RS
69
© 2013, OpenTravel Alliance. All rights reserved.
Message Pair Overview
The OpenTravel Air Check In message pair provides air travel check-in function specifically for the self-service
channels (kiosks, web and mobile).
These messages allow customers to check-in for eligible flights using various channels (kiosks, web and mobile)
and provide the ability to perform related functions such as checking baggage, issue bag tags, boarding passes
and entering further passenger information (APIS data etc.)
OTA_AirDemandTicketRQ/RS
Message Pair Overview
The OpenTravel Air Demand Ticketing message pair provides air travel ticketing functionality used for request-
ing ticket fulfillment.
OTA_AirDisplayQueueRS
Message Pair Overview
The OpenTravel OTA_ReadRQ and Air Display Queue response messages are used to display booking files on a
queue. The booking file data can be requested in full format whereby the booking file(s) on that queue will be
returned or in condensed format containing queue information. This data will be used for queuing and booking
reference. Additionally, the items can be removed from queue (by displaying them) or left on the respective
queue.
OTA_AirFareDisplayRQ/RS
Message Pair Overview
The OpenTravel Air Fare Display message pair allow clients to request information on fares which exist between
a city pair for a particular date or date range. No Inventory check for available seats on flights is performed by
the server before returning the Fare Display Response message.
The request can optionally contain information indicating that a more specific response is required. This infor-
mation can include passenger information, specific flight information and information on the types of fares that
the client is interested in. The response message contains repeating FareDisplayInfo elements, each of which
contains information on a specific fare contract including airline, travel dates, restrictions and pricing. It can
optionally return information on other types of fares that exist, but have not been included in this response.
OTA_AirFlifoRQ/RS
Message Pair Overview
The OpenTravel Air Flight Information message pair provides updated information on the operation of a specific
airline flight. The request requires the airline, flight number and departure date. The departure and arrival air-
port locations can be also be included.
The message response includes real-time flight departure and arrival information. The following flight operation
data is included in the response:
- Departure airport
- Arrival airport
70
© 2013, OpenTravel Alliance. All rights reserved.
- Marketing and operating airline names, when applicable
- Flight number
- Type of equipment
- Status of current operation
- Reason for delay or cancellation
- Airport location for diversion of flight
- Current departure and arrival date and time
- Scheduled departure and arrival date and time
- Duration of flight
- Flight mileage
- Baggage claim location
OTA_AirDetailsRQ/RS
Message Pair Overview
The OpenTravel Air Details message pair provides flight leg and codeshare information for a specific flight on a
specific date between a city pair.
The Air Details Response message contains airline, arrival and departure times, equipment, meal, and duration
information (total and ground) for each leg of a flight. It also contains codeshare information, on time percent-
age, and electronic ticketing eligibility.
OTA_AirLowFareSearchRQ/RS
Message Pair Overview
The OpenTravel Air Low Fare Search message pair provides priced itinerary options for flights between specific
city pairs on certain dates for specific numbers and types of passengers. Optional request information can in-
clude:
- Time / Time Window
- Connecting cities.
- Client Preferences (airlines, cabin, flight types etc.)
- Flight type (nonstop or direct)
- Number of itinerary options desired
The Air Low Fare Search response message contains a number of ‘Priced Itinerary’ options. Each includes:
- A set of available flights matching the client’s request.
- Pricing information including taxes and full fare breakdown for each passenger type
- Ticketing informationticket advisory information and ticketing time limits.
- Fare basis codes and the information necessary to make a rules entry.
71
© 2013, OpenTravel Alliance. All rights reserved.
OTA_AirPriceRQ/RS
Message Pair Overview
The OpenTravel Air Price message pair provides pricing information for specific flights on certain dates for a
specific number and type of passengers.
The message allows for optional information such as fare restriction preferences and negotiated fare contract
codes to be included.
The pricing request contains the information necessary to perform an availability / sell from availability / price
series of entries on an airline CRS or GDS.
The pricing response message contains a ‘Priced Itinerary’. This includes:
- The set of flights sent in the pricing request message
- Pricing information including taxes and full fare breakdown for each passenger type
- Ticketing information
- Fare Basis Codes and the information necessary to make a Fare Rules entry.
OTA_AirRulesRQ/RS
Message Pair Overview
The OpenTravel Air Rules message pair provides text rules for a specific fare basis code for an airline and city
pair on a specific date. Optional information allows negotiated fare contract codes to be included in the request.
The response message contains a set of text (human readable) rule information paragraphs. Each paragraph is
identified by a rule code.
OTA_AirScheduleRQ/RS
Message Pair Overview
The OpenTravel Air Schedules message pair provides a customer or a third party entity with the ability to view
airline flight schedules. This message pair requires the customer to specify the departure and arrival cities for a
specific date. It offers flight information on airlines that provide service between the requested cities.
The Air Schedules messages could be used for the following circumstances:
- A customer wants to determine what airlines offer service to/from specific cities.
- A customer is looking for a specific flight number. By entering the arrival and departure cities and know-
ing the approximate arrival or departure time the customer can locate their specific flight number.
- A customer needs to determine the days of the week that service is scheduled to and from the requested
destination.
- A customer wants to know the type of aircraft used to fly a route. Some customers prefer to fly on larger
types of aircraft.
The Air Schedules message also contains other information that customers may be interested in, including:
- Meal service
- Duration of flight
- On-time statistics
- Smoking allowed indicator
72
© 2013, OpenTravel Alliance. All rights reserved.
In addition, these messages provide the foundation for electronic timetables.
OTA_AirSeatMapRQ/RS
Message Pair Overview
The OpenTravel Air Seat Map message pair display the seats that are available for a given flight, as well as their
location within the aircraft. To make a seat assignment when using an online booking product, a customer will
frequently access a seat map display to determine which seats are available and then they will make a separate
seating request.
These messages identify all the information necessary to request and return an available seat map for a particu-
lar flight. Types of information for the seat map request include: airline, flight number, date of travel, class of
service and frequent flier status.
The response message includes: flight, aircraft and seat description information.
OTA_AirBookModifyRQ/OTA_AirBookRS
Message Pair Overview
The OpenTravel Air Book Modify Request/ Air Book Response message pair modify an existing booking file. The
message contains all elements of the OTA_AirBookRQ message, plus a general type of modification, e.g. name
change, split, cancel or other, is indicated within the ‘ModificationType’ attribute.
The modification operation on the different elements is either indicated with the existing attribute ‘Status’ (for
air segments, SSR’s and seat requests) or with attribute ‘Operation’ of Type ActionType for the other elements
(e.g. Other service information, remarks, AirTraveler Elements, etc.).
All the data to be changed is submitted in the AirBookModifyRQ element, while the AirReservation element con-
tains all existing data. This allows the receiving system to perform a consistency check before updating the book-
ing file. Please note that in order to keep the message small, the existing information could be omitted.
Please note that changes to a booking may result in required updates of the ticket (e.g. re-validation), implied
charges for a change, altered pricing and/or the generation of some fees that may need to be collected, and these
ticketing, pricing and fulfillment operations are not in scope for this message pair nor referenced in the follow-
ing use cases.
The response to the OTA_AirBookModifyRQ message is the OTA_AirBookRS message.
OTA_AirGetOfferRQ/RS
Message Pair Overview
The Get Offer request message provides trip and passenger characteristics to be used by an offer processing sys-
tem to target relevant offers. Request criteria may be specified for the entire trip or by individual traveler and/or
arranger and include any combination of the following:
- Confirmed booking including air itinerary, traveler/arranger, purchased offers, payment, pricing and
ticketing information
- Pre-booking including origin/destination, itinerary, traveler/arranger preferences and specific flight
information
- Baggage including item type, quantity, description, origin/destination, marketing/operating carriers
and traveler/itinerary association
73
© 2013, OpenTravel Alliance. All rights reserved.
- Seat information including marketing classification, requested quantity and traveler/itinerary associa-
tion
- Offers to include and/or exclude
- Offers that have already been presented and/or purchased
Additional supported business functionality includes:
- Offer family encoding by airline suppliers and/or ATPCO
- Detailed point of sale information
- Pricing structure flexibility, including display/ pricing currency(s), ticketing country/ city, and loyalty
program redemption support
- Offer stages that specify the stage in the journey at which the ancillary offer request is being made or the
offer was purchased, e.g. shopping and check-in
- Travel insurance product offers included with ancillary offers
The Get Offer response message returns relevant offers that meet the search criteria. Returned information in-
cludes:
- Pricing structure detailsincluding exchange rates, currency overrides and accepted payment currency
that apply to all offers unless override information is provided elsewhere in the message
- Priced offersPriced offer information, including offer name and description, maximum and minimum
offer quantity(s), service family, pricing details including redemption mile pricing, booking instructions,
restrictions, penalties, multimedia, commissions and currency overrides
74
© 2013, OpenTravel Alliance. All rights reserved.
CAR MESSAGES
Messages Overview
There are several OpenTravel Car Messages that provide a wide range of functionality, including:
Vehicle search with availability & rates - The OpenTravel Vehicle Availability with Rates message could be used
in any of the following circumstances:
A customer is performing a simple booking and will come into the branch office to pick-up and drop off the vehi-
cle.
A customer requires a pick-up service at his/her home or office. In this case the Off Location Services element
can be used to provide basic address information as well as special instructions.
A customer requires a delivery and collection service, where a car will be delivered to a specific location and the
keys left in a secure place. Again, the Off Location Services element can be used to hold address information as
well as special instructions.
- Make, modify and cancel reservations - The OpenTravel Vehicle Reservation (make) message pair is in-
tended for a single reservation. The OpenTravel Vehicle Modify message pair is intended for customers
to change information on an existing reservation. The OpenTravel Vehicle Cancel message pair is an ex-
tension of the generic OpenTravel cancel functionality (OTA_CancelRQ/RS.) To cancel a reservation,
the trading partner or customer provides the supplier or integrator with the exact Unique ID for the res-
ervation. If the Unique ID is unknown, the trading partner may use the generic OpenTravel Retrieve
Reservation (OTA_ReadRQ/OTA_ResRetrieveRS) message pair to search for an exact match.
- Inventory reporting/ notification - The OpenTravel Vehicle Rental Location Detail message pair pro-
vides detail information regarding a vendor’s location based on an input location code.
- Vehicle check in and check out - The OpenTravel Vehicle Check In message pair provides the detail in-
formation related to the return of a rented vehicle to systems with a “need to know” that a vehicle has
been returned and the rental agreement closed. The OpenTravel Check Out message pair provides all the
data fields needed to capture the pertinent detail data related to renting a specific car to a customer, and
send that information to automated systems that have a “need to know” that a rental vehicle was
“checked out.”
- Vehicle location details reporting/ notification - The OpenTravel Vehicle Location Details Notification
message pair provides the capability for a car supplier to send location detail information to another sys-
tem for the purpose of updating the other system’s database.
- Vehicle exchange - The OpenTravel Vehicle Exchange message pair provides the capability to exchange a
vehicle. This message differs from an OTA_VehCheckOutRQ/RS in that a vehicle exchange is a special-
ized version of a check in/check out message in that it provides the ability to put the details of two vehi-
cles inside one message.
- Rental location information reporting - The OpenTravel Vehicle Rental Location Detail message pair
provides detailed information regarding a vendor’s location based on an input location code.
- Location-based search for vehicle vendors - The OpenTravel Vehicle Location Search message pair pro-
vides for a search of vendor locations based on input criteria.
- Rate plan requests & notification - The OpenTravel Vehicle Rate Plan Notification message pair provides
the capability for a car supplier to send rate detail information to another system for the purpose of
populating the other system’s database.
- Rate rules requests & notification - The OpenTravel Vehicle Rate Rule Notification message pair pro-
vides the capability for a car supplier to send rate rules information to another system for the purpose of
populating the other system’s database. The OpenTravel Vehicle Rate Rule message pair provides the
capability for a car supplier to send rate rules information to another system for the purpose of populat-
ing the other system’s database.
75
© 2013, OpenTravel Alliance. All rights reserved.
- Vehicle reservation status notification - The OpenTravel Vehicle Reservation Status Notification mes-
sage pair is intended for updating a single reservation. Typically, a reservation message (e.g.,
OTA_VehResRQ/RS), which resulted in a pending reservation, has been exchanged between two trad-
ing partners (e.g., a GDS and the car rental company) prior to this Reservation Notification message
pair.
Messages List
- OTA_VehicleCommonTypes
- OTA_VehAvailRateRQ/RS
- OTA_VehCancelRQ/RS
- OTA_VehCheckOutRQ/RS
- OTA_VehCheckInRQ/RS
- OTA_VehLocDetailsNotifRQ/RS
- OTA_VehExchangeRQ/RS
- OTA_VehLocDetailRQ/RS
- OTA_VehLocSearchRQ/RS
- OTA_VehModifyRQ/RS
- OTA_VehRateNotifRQ/RS
- OTA_VehRateRuleNotifRQ/RS
- OTA_VehRateRuleRQ/RS
- OTA_VehResRQ/RS
- OTA_VehResStatusNotifRQ/RS
- OTA_VehRetResRQ/RS
- OTA_VehResNotifRQ/RS
76
© 2013, OpenTravel Alliance. All rights reserved.
OTA_VehAvailRateRQ/RS
Message Pair Overview
The OpenTravel Vehicle Availability with Rates message pair is intended for a simple reservation. This message
pair assumes the customer has already performed a location search and has found a specific rental branch. This
message is typically used in the following circumstances:
- A customer is performing a simple booking and will come into the branch office to pick-up and drop off
the vehicle.
- A customer requires a pick-up service at his/her home or office. In this case the Off Location Services el-
ement (OffLocService) can be used to provide basic address information as well as special instructions.
- A customer requires a delivery and collection service, where a car will be delivered to a specific location
and the keys left in a secure place. Again, the Off Location Services element can be used to hold address
information as well as special instructions.
Other Message Pair Notes & Features:
- Only one set of date/times may be specified for the availability message, e.g. multiple dates and times
will require multiple messages.
- Special equipment, such as hand controls or a baby seat can be accommodated through this message
pair.
- Special equipment may be associated with a specific car , rather than as part of the more general reserva-
tion.
- Special circumstances such as chauffeur-driven cars are not accommodated in this message.
- The root tag of the OTA_VehAvailRateRQ contains standard payload attributes found in all OpenTravel
payload documents. Because the results of the search message could be quite numerous, the request also
has an attribute, MaxResponses, indicating the number of replies requested. The attribute ReqRespVer-
sion is a positive integer value that indicates the version number requested for the response message.
OTA_VehCancelRQ/RS
Message Pair Overview
The OpenTravel Vehicle Cancel (reservation) message pair is an extension of the generic OpenTravel cancel
functionality (OTA_CancelRQ/RS.)
To cancel a reservation, the trading partner or customer must provide the supplier or integrator with the exact
Unique ID for the reservation. If the Unique ID is unknown, the trading partner may use the generic OpenTravel
Retrieve Reservation (OTA_ReadRQ/OTA_ResRetrieveRS) message pair to search for an exact match.
This message pair can be supports both single and two-phase approaches. In a single-phase approach, the cus-
tomer simply requests to “cancel this reservation”. A two-phase approach introduces the concept of a “what if”
question, e.g. “What if I cancel this reservation?”
The response to the first phase will identify any penalties, any subsequent costs, etc. The second phase is where
the action is confirmed to “go ahead and complete the request” or “ignore the request I just sent.”
The purpose of the request message is indicated using the “Type” Attribute:
- Initiateindicates the initial request
- Ignorestop the request
- Confirmto complete the modification
77
© 2013, OpenTravel Alliance. All rights reserved.
The state of the reservation is then indicated in the response message using the Status Attribute:
- Pendingcancellation is possible but not completed
- Ignoredcancellation ignored
- Cancelledcancellation completed
Other Message Pair Notes & Features:
- This message pair does not require a prior Retrieve Reservation ( OTA_VehResRQ/RS) message, BUT
some suppliers may require a Retrieve Reservation message to be used prior to a Cancel message, so
check your trading partner requirements.
- This message pair can only be used to cancel a single, specific reservation; it cannot be used to cancel
multiple reservations at one time.
- The generic OpenTravel cancel response message pair (OTA_CancelRQ/RS) has been extended to pro-
vide additional details of the vehicle reservation information to the customer. This will aid the customer
in understanding the consequences of a cancellation.
OTA_VehCheckOutRQ/RS
Message Pair Overview
The OpenTravel Vehicle Check Out message pair provides all the data fields needed to capture the pertinent data
related to renting a specific car to a customer, and send that information to automated systems that have a “need
to know” that a rental vehicle was “checked out.” This would include rental location, customer information,
payment information, intended length of rental, and monetary amounts for vehicle rental, surcharges, fees, tax-
es, insurance, and ancillary services and equipment.
The “need to know” systems could be travel agent, car rental agency inventory management, or OpenTravel
partner hosted systems.
The Vehicle Check Out response message confirms that the rental agreement is active or requests additional in-
formation.
- Vehicle Check Out messages could be used in any of the following circumstances:
- Initiate a Check Out transaction utilizing an existing reservation
- Initiate a Check Out transaction without an existing reservation, based on a vehicle request
Only one “vehicle rental” request at a time may be made with the Vehicle Check Out. The response will include
any legal wording related to the rental transaction.
OTA_VehCheckInRQ/RS
Message Pair Overview
The OpenTravel Vehicle Check In message pair provides the detail information related to the return of a rented
vehicle to systems with a “need to know” that a vehicle has been returned and the rental agreement closed.
The detail information includes date and time of return, condition (e.g. damage, fuel, mileage) of the vehicle and
associated equipment, location of the return, and method of payment. This information is sent to systems that
need to know that the vehicle can be returned to inventory, and that a rental agreement can be closed and the
customer billed for the financial charges associated with renting the vehicle.
The Vehicle Check In response message confirms that the rental agreement is closed or requests additional in-
formation.
78
© 2013, OpenTravel Alliance. All rights reserved.
Vehicle Check In messages are typically used to initiate a check in transaction utilizing an existing rental agree-
ment.
Only one “vehicle return” request at a time may be made with the Vehicle Check In message. The response will
include any legal wording related to the rental transaction.
OTA_VehLocDetailsNotifRQ/RS
Message Pair Overview
The OpenTravel Vehicle Location Details Notification message pair provides the capability for a car supplier to
send location detail information to another system for the purpose of updating the other system’s database.
Multiple vehicle locations can be sent in one message and the action to be taken may include:
- Adding, deleting or doing a full replace on a location
- Adding, deleting, or replacing certain items of data for an existing location
OTA_VehExchangeRQ/RS
Message Pair Overview
The OpenTravel Vehicle Exchange message pair provides the capability to exchange a vehicle. This message dif-
fers from an OTA_VehCheckOutRQ/RS in that a vehicle exchange is a specialized version of a check in/check
out message that provides the ability to put the details of two vehicles inside one message.
This transaction is part of a rental scenario and does not create a separate rental agreement. The message only
accommodates one vehicle exchange at a time (e.g., group exchanges are not accommodated). Additionally, the
message assumes an exchange will be made on a one-to-one basis (e.g. you won’t exchange 1 car for 2 cars).
The vehicle exchange message requires an identifying rental agreement number. The response may contain de-
tailed charge information for the customer and any legal wording related to the rental transaction.
The vehicle exchange request message provides the data related to exchanging a specific car with another car
and sending that information to automated systems that need to know that rental vehicles were exchanged.
These systems could include car rental agency inventory management or OpenTravel travel partner hosted sys-
tems. This data may include, but is not limited to, contract number, rental location, reason for exchange, ex-
change location, incoming vehicle information, and outgoing vehicle information. Vehicle information may in-
clude incoming and outgoing vehicle asset numbers, fuel levels, and damage information, etc.
This vehicle exchange message does not change original car fuel level or conditions from the checkout. That data
is available from the back-end system by recalling the original check out information.
OTA_VehLocDetailRQ/RS
Message Pair Overview
The OpenTravel Vehicle Rental Location Detail message pair provides detailed information regarding a vendor’s
location based on an input location code. Only one location can be requested in each message.
The Vehicle Rental Location Detail response message returns detailed information regarding a vendor’s location.
The returned information may include full address, phone number, hours of operation, delivery/collection ser-
vices, seasonal dates open, customer loyalty services and hours, special program participation and credit cards
accepted.
79
© 2013, OpenTravel Alliance. All rights reserved.
OTA_VehLocSearchRQ/RS
Message Pair Overview
The OpenTravel Vehicle Location Search message pair provides for a search of vendor locations based on input
criteria. This allows a customer to find a location that is non-airport or a location when the customer does not
know the airport code.
The criteria must be one or more of the following:
- A full address
- Zip/postal code
- Area code
- Area code/exchange
- Landmark name
Note that only one search may be requested in the OTA_VehLocSearchRQ message. Multiple searches requires
the sending of multiple OTA_VehLocSearchRQ messages.
In the response, one or more vendor locations may be returned in a list format. The message includes high-level
information such as specific address and number of miles from the requested criteria.
OTA_VehModifyRQ/RS
Message Pair Overview
The OpenTravel Vehicle Modify message pair is intended for customers to change information for an existing
reservation.
The Vehicle Modify message pair does not require a Vehicle Retrieve Reservation (OTA_VehResRQ/RS) mes-
sage pair to be used prior to the modify, but they may be used in conjunction with one.
This message pair can only be used for a single, specific reservation and cannot be used to change multiple res-
ervations at one time.
A Vehicle Modify message can be a single phase or two-phase approach. For a single-phase message the client
simply requests to “modify this reservation as follows….”. A two-phase message introduces the concept of a
“what if” question (what if I modify this message as follows?). The response to the first phase will identify any
penalties, any subsequent costs, etc. The second phase is where the action is confirmed to “go ahead and com-
plete the request” or “ignore the request I just sent.”
The purpose of the request message is indicated using the Type Attribute:
- Initiateindicates the initial request
- Ignorestop the request
- Confirmto complete the modification
The state of the response message using the Status Attribute:
- Pendingmodification is possible but not completed
- Ignoredmodification ignored
- Cancelledmodification completed
The Vehicle Modify message pair is typically used in the following circumstances:
- A flight has been delayed or canceled and a customer needs to update their reservation arrival.
80
© 2013, OpenTravel Alliance. All rights reserved.
- A customer has additional passengers and needs to change the car originally reserved.
- A customer now requires special equipment that was not on their original reservation.
- A customer has changed travel plans to fly in to a different city and needs to adjust the arrival city.
- A customer has changed travel plans to fly in or out on a different date and/or time and needs to adjust
the dates and/or times. (See Use Case 1)
- A customer originally listed on the reservation is not going so the name on the reservation needs to
change.
- A customer has received a promotional offer after making a reservation and wants to use it for the reser-
vation. (See Use case 2)
- Other situations as determined by trading partners (as there are many other individual elements that
could be changed but these are too numerous to list.)
OTA_VehRateNotifRQ/RS
Message Pair Overview
The OpenTravel Vehicle Rate Plan Notification message pair allows car suppliers to send rate detail information
to another system for the purpose of populating the other system’s database. Multiple rates can be sent in one
message and the action to be taken may include creating, deleting or updating a rate.
The request message is a “push” message. The intended partners are the car supplier systems, the CRS, a GDS,
revenue management systems, etc.
OTA_VehRateRuleNotifRS/RS
Message Pair Overview
The OpenTravel Vehicle Rate Rule Notification message pair provides the capability for a car supplier to send
rate rules information to another system for the purpose of populating the other system’s database. The rules are
related to a rate and used to further define a rate. Multiple rules can be sent in one message and the action to be
taken may include creating, deleting or updating a rule.
The request message is a “push” message. The intended partners are the car supplier systems, the CRS, the GDS
and the revenue management systems.
OTA_VehRateRuleRQ/RS
Message Pair Overview
The OpenTravel Vehicle Rate Rule message pair provides the capability for a car supplier to send rate rules in-
formation to another system for the purpose of populating the other system’s database. The rules are related to a
rate and used to further define a rate. Multiple rules can be sent in one message and the action to be taken may
include creating, deleting or updating a rule.
The request message is a “pull” message. The intended partners are the car supplier systems, the CRS, the GDS
and the revenue management systems.
81
© 2013, OpenTravel Alliance. All rights reserved.
OTA_VehResRQ/RS
Message Pair Overview
The OpenTravel Vehicle Reservation message pair is intended for a single reservation. This message pair re-
quires the customer to specify the location, either by a location search or by knowledge of the rental facility, and
assumes the customer has already performed some kind of location search and pinpointed a specific rental
branch.
An Availability with Rates (OTA_VehAvailRateRQ/RS) message pair may be exchanged prior to the Vehicle
Reservation message pair, but is not necessary. A vendor may make a single reservation upon receiving only the
reservation message.
The Vehicle Reservation messages are typically used in the following circumstances:
- A customer is performing a single booking and will come into the branch office to pick-up and drop off
the vehicle.
- A customer requires a pick-up service at their home or office. In this case, the Off Location Services (Of-
fLocService) element can be used to provide basic address information as well as special instructions.
- A customer requires delivery and collection service, where a car will be delivered to a specific location
and the keys left in a secure place. Again, the Off Location Services (OffLocService) element can be used
to hold address information as well as special instructions.
- Rates are already known to the customer or trading partner and only a reservation is needed to com-
municate the rental need. Special equipment, such as hand controls or a baby seat can be accommodat-
ed through this message pair. Special equipment can be returned related to a specific car, rather than as
part of the more general reservation. Special circumstances such as chauffeur-driven cars are not ac-
commodated in this message.
OTA_VehResStatusNotifRQ/RS
Message Pair Overview
The OpenTravel Vehicle Reservation Status Notification message pair is intended for updating a single reserva-
tion.
Typically, a reservation message (e.g., OTA_VehResRQ/RS), which resulted in a pending reservation, has been
exchanged between two trading partners (e.g., a GDS and the car rental company) prior to this Reservation Sta-
tus Notification message pair.
OTA_VehRetResRQ/RS
Message Pair Overview
The OpenTravel Vehicle Retrieve Reservation message pair is intended for customers to display their previously
made reservation(s). This message pair allows a customer to retrieve one specific reservation or receive a list of
reservations that match specific criteria.
One of the following is required to complete a Vehicle Retrieve Reservation request:
A Unique ID
Customer Loyalty Number, or
Person Name.
82
© 2013, OpenTravel Alliance. All rights reserved.
Many companies may require a combination of these three. Other optional items are pickup information, tele-
phone number, and vendor.
Trading partners may mandate that additional fields are mandatory. In the case where a list of reservations is
retrieved, the list will provide key high- level information; such as, dates and times, pick-up location, name and
type of class of the vehicle. From this list, the customer can then drill down and retrieve one specific reservation.
The Vehicle Retrieve Reservation message pair are typically used in the following circumstances:
- A customer wants to verify that all information is accurate as the reservation may have been made
months ago or by a third party. The traveler can verify that the reservation was made accurately and that
pertinent information has not changed from the time the reservation was made.
- A customer is on the road and does not have their itinerary for their next location. Depending on the
trading partner, this customer can retrieve the reservation and see their next location or a list of loca-
tions to which they are going.
- A customer needs to modify their reservation. Depending on the trading partner, a Vehicle Retrieve Res-
ervation (OTA_VehResRQ/RS ) transaction may be required before the Vehicle Modify is done.
- A customer wants to modify or cancel an existing reservation, but does not have the Unique ID (reserva-
tion number). In this case, the retrieve message ( OTA_VehResRQ/RS) could be used to retrieve a list of
reservations that match the search criteria and the customer could then select a single reservation from
the list on which to perform further action.
OTA_VehResNotifRQ/RS
Message Pair Overview
The OpenTravel Vehicle Reservation Notification message pair addresses a common business need to be able to
bulk transfer entire reservations between computer systems. Other OpenTravel vehicle messages support re-
questing new reservations and retrieving existing reservation information in a client/server style pull operation,
however, they don't support transferring bulk reservation information in a notification style push operation like
this message pair does.
To simplify retransmission logic, reservations are transferred in a transactional (all or nothing) model. If the
receiver sends a response message with a Success element, all reservation information has been successfully
transferred.
If the response contains an Error element, none of the reservation information has been transferred and the in-
formation should be retransmitted at a later time.
Each reservation included in the request message may include the following information:
- Confirmation number
- Reservation status (new, changed, canceled)
- Itinerary information
- Vehicle selection
- Pricing information
- Booking source information
- Coverage requested
- Optional equipment requested
- Special request comments
The intended partners are reservation systems, counter level systems, fleet management systems, accounting
systems, and other trading partners.
83
© 2013, OpenTravel Alliance. All rights reserved.
CRUISE MESSAGES
Messages Overview
Booking a cruise reservation typically involves searching for the cruise followed by the creation of the booking.
First, the traveler decides when and where the cruise is to be taken. After the sailing has been selected the travel-
er decides on the fare type and accommodation costs. Finally the cruise is purchased.
In the following section, the term “traveler” will be used. This could be a travel agency, a travel partner, a GDS,
or anyone the cruise line has authorized to make bookings using these messages.
To book a cruise, the traveler typically performs the following steps:
1. Search for a sailing using the CruiseSailAvailRQ/RS message pair which could be sent to one or more cruise
lines. The cruise line(s) would reply with a list of sailings or a warning to inform the requester that no sailings
are available that satisfy the request. Once a sailing is chosen, all subsequent messages will only be sent to the
selected cruise line.
2. Request available fares for the selected voyage with the CruiseFareAvailRQ/RS message pair. A list of availa-
ble fares will be returned by the cruise line and the traveler selects a fare.
3. Request the available categories using the CruiseCategoryAvailRQ/RS message pair. A list of available catego-
ries will be returned by the cruise line and the traveler selects a category.
4. After the category has been selected, and any time prior to creating the booking, pricing can be requested with
the CruisePriceBookingRQ/RS message pair. The cruise line will return all of the pricing items for both the indi-
vidual traveler and the booking.
5. Request a list of available cabins in the selected category with the CruiseCabinAvailRQ/RS message pair. The
cruise line will return a list of available cabins from which the traveler will make a selection.
6. Place one or more cabins on hold using the CruiseCabinHoldRQ/RS message pair. This takes the cabin(s) out
of the cruise line’s available inventory for a short period of time, typically fifteen minutes.
7. If the traveler decides to request one or more different cabins to be held, the CruiseCabinUnholdRQ/RS mes-
sage pair is used to release the specific cabin(s) currently on hold.
8. The traveler creates a booking with the CruiseBookRQ/RS message pair. In the request message, the traveler
advises the cruise line of all required information for all accompanying passengers. The cruise line responds with
the reservation number to confirm the booking.
Alternatively, if a traveler knows the cruise line’s available voyages and fares, there would be no need to use the
CruiseSailAvailRQ/RS or the CruiseFareAvailRQ/RS message pairs. The traveler would start the shopping pro-
cess by requesting the available categories for a selected fare for a selected sailing.
Other business operations supported by the OpenTravel Cruise messages include:
- Cancellations - Request the penalties for both the booking and the individual travelers that would be
charged if the requested cruise reservation is canceled using the CruiseCancellationPricingRQ/RS mes-
sage pairs.
- Dining Options - The CruiseDiningAvailRQ/RS message pair allow requests for dining options for a se-
lected voyage and fare code and returns a list of dinings available for a given sailing and for a selected
fare.
- Fast Sells The CruiseFastSellRQ message is a multipurpose request to access one of the following
cruise provider functions: Cabin hold (maximum of 4 cabins) when a cabin number is provided; Cabin
availability when a cabin number is not provided and a category is provided; Category availability when
neither cabin, nor category is specified in the request; Fare availability when the fare code provided in
the request is either incorrect for the sailing or not available; and, Package availability when the package
is specified, but not available for the sailing.
84
© 2013, OpenTravel Alliance. All rights reserved.
- Cruise Information - The CruiseInfoRQ/RS message pair allows the sharing of miscellaneous structured
cruise information, including: cruise ship characteristics; embark/debark time; cruise policies; and
cruise line contacts.
- Cruise Itineraries - The CruiseItineraryDescRQ/RS message allows customers to request the detailed
itinerary of a specific sailing.
- Cruise Payments - The CruisePaymentRQ/RS message pair provides a traveler with the ability to submit
payments for an existing reservation without first retrieving the reservation.
- Cruise Packages The CruisePkgAvailRQ/RS message pair is used to request information about the
pre-cruise, post-cruise, or the inclusive-cruise packages associated with a sailing.
- PNR Updates The CruisePNR_UpdateNotifRQ/RS message pair provides a defined structure to push
unsolicited update messages (such as change in departure time and cancellation for non payment) to a
travel partner to enable passenger record synchronization between the cruise line company and a travel
partner.
- Shore Excursions The CruiseShorexAvailRQ/RS message pair is used to request information about
shore excursions associated with a sailing (such as a sight seeing tour or a shopping expedition).
- Special Services The CruiseSpecialServicesRQ/RS message pair is used for requests about special ser-
vices offered for a given sailing/reservation ID or to request details for a specific special service.
Messages List
- OTA_CruiseCommonTypes
- OTA_CruiseBookingDocumentRQ/RS
- OTA_ReadRQ/OTA_CruiseBookingHistoryRS
- OTA_CruiseCabinAvailRQ/RS
- OTA_CruiseCabinHoldRQ/RS
- OTA_CruiseCabinUnholdRQ/RS
- OTA_CruiseCancellationPricingRQ/RS
- OTA_CruiseCategoryAvailRQ/RS
- OTA_CruiseBookRQ/RS
- OTA_CruiseDiningAvailRQ/RS
- OTA_CruiseFareAvailRQ/RS
- OTA_CruiseFastSellRQ
- OTA_CruiseInfoRQ/RS
- OTA_CruiseItineraryDescRQ/RS
- OTA_CruisePaymentRQ/RS
- OTA_CruisePkgAvailRQ/RS
- OTA_CruisePriceBookingRQ/RS
- OTA_CruisePNR_UpdateNotifRQ/RS
- OTA_CruiseSailAvailRQ/RS
- OTA_CruiseShorexAvailRQ/RS
- OTA_CruiseSpecialServicesRQ/RS
85
© 2013, OpenTravel Alliance. All rights reserved.
OTA_CruiseBookingDocumentRQ/RS
Message Pair Overview
The OpenTravel Cruise Booking Document message pair provides the ability to request a document type and its
delivery method without first having to retrieve the reservation.
The request message is the OTA_CruiseBookingDocumentRQ in which the user can specify the reservation ID
and the type of document (e.g., cruise itinerary, air itinerary etc.) the user wants along with a delivery mode
(e.g., e-mail, fax, mail etc.)
The user may optionally provide a phone number, an e-mail address or and address to where the document is to
be sent. If no phone number, e-mail or address is specified then the information provided within the booking is
used.
The response message OTA_CruiseBookingDocumentRS returns the status of each delivery request that was
made.
OTA_ReadRQ/OTA_CruiseBookingHistoryRS
Message Pair Overview
The OpenTravel Cruise Booking History message pair provides change/service history on an existing reserva-
tion.
The request message is the OTA_ReadRQ with which a user can specify the reservation ID for which they want
to see the change history for. The OTA_ReadRQ message is also used to retrieve the reservation information and
an indicator that distinguishes the service history request from the request for the current reservation infor-
mation.
The response message OTA_CruiseBookingHistoryRS returns a list of history entries for the reservation changes
that have taken place.
OTA_CruiseCabinAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Cabin Availability message pair provides a list of available cabins for a selected category
on a voyage. The voyage information is defined by the VoyageID or the departure date and duration, depending
on the cruise line. The fare code and the berthed and priced category codes are retained from the respective
availability message.
The Cruise Cabin Availability request message requests Cabin Availability for a given sailing with a specific mode
of transportation/ gateway city pair & currency, and for a selected fare/category pair. Optional request infor-
mation can include: Guest city and Inclusive package.
The Cruise Cabin Availability response message contains a list of cabins available for a given sailing with a spe-
cific mode of transportation/ gateway city pair & currency and for a selected fare/category pair. For each cabin
the following information may be returned: cabin number; position in ship; ship side; category location; remark;
deck name; bed options; maximum cabin occupancy; cabin size; berthed category code; priced category code;
status code; category indicator; cruise package information; group code; fare code; currency code; and market-
ing message.
86
© 2013, OpenTravel Alliance. All rights reserved.
OTA_CruiseCabinHoldRQ/RS
Message Pair Overview
The OpenTravel Cruise Cabin Hold message pair instructs a cruise line to remove a selected cabin from available
inventory for a short time interval, typically fifteen minutes. This allows the user time to enter additional infor-
mation which is required to complete the booking, without concern for losing the cabin.
The voyage is identified by the VoyageID or the departure date and duration, depending on the cruise line. Mul-
tiple cabins are usually allowed to be placed on hold, up to a maximum defined by the cruise lines.
The response message indicates the status of each cabin for which a hold is requested. It is conceivable in the
case of a request containing multiple cabins, that the status might be different for one or more cabins. If the cab-
in hold request was successful, the cruise line usually provides additional information in the response, such as
the acceptable forms of payment.
The cruise line also may indicate the length of time the cabin will be held before being automatically released
back into inventory, as well as which data elements the cruise line requires to complete the booking, dining, in-
surance, and other options.
OTA_CruiseCabinUnholdRQ/RS
Message Pair Overview
The OpenTravel Cruise Cabin Unhold message pair is used to release a hold that was previously put on a cabin,
allowing the cruise line to release the cabin back into its available inventory.
The request message allows the user to release multiple cabins-from multiple voyages-to address situations
where the same cabin is currently held for back-to-back cruises. The voyage is identified by the VoyageID or the
departure date and duration, depending on the cruise line.
The response message indicates the status for each cabin in the request. If unsuccessful, a warning or advisory
message is usually returned.
OTA_CruiseCancellationPricingRQ/RS
Message Pair Overview
The OpenTravel Cruise Cancellation Pricing message pair is sent to a cruise line vendor to request the penalties
that would be charged if the requested reservation is canceled. The response message returns the penalties for
both the booking and the individual travelers.
OTA_CruiseCategoryAvailRQ/RS
Message Pair Overview
The OpenTravel Category Availability message pair requests a list of cabin categories for a specified voyage and
fare code. The voyage information is indicated by either the VoyageID or the departure date and duration de-
pending on the cruise line.
The Category Availability Request message requests Category Availability for a given sailing with a specific Mode
of Transportation/GatewayCity pair and currency and for selected fares (depending on the cruise line). Optional
request information can include: Guest ages; Guest city; and Inclusive package.
The response message returns a list of cabin categories that correspond to the requested sailing and fare. In ad-
dition to the status, the response typically contains information about the location of the category on the ship,
87
© 2013, OpenTravel Alliance. All rights reserved.
the maximum occupancy of the cabins, priced and berthed codes, as well as price information about the catego-
ry.
OTA_CruiseBookRQ/RS
Message Pair Overview
The OpenTravel Cruise Book message pair is used to create a reservation on the cruise line reservation system,
for a specific sailing, with a specified mode of transportation/gateway city pair and currency, and a selected
fare/category pair, for one or more passengers, in a specific cabin. Typically the request would be made by a
Global Distribution System (GDS) or an Internet booker, or another travel broker. Prior to submitting a Create
Booking request message, a cabin must have been placed on hold. The only exception to this is if a cabin is re-
served as a guarantee, rather than a specific cabin.
The response message indicates if the request was successful, and returns a Reservation ID number and may
also integrate the booking into a GDS' PNR based on the cruise line reply.
OTA_CruiseDiningAvailRQ/RS
Message Pair Overview
The OpenTravel Dining Availability message pair provides a list of dining options for a selected voyage and fare
code. The voyage information will be entered via the VoyageIDor the departure date and durationdepending
on the cruise line and guest count is required. Optional request information can include:
- Dining Room name
- Dining Room operation times
- Type of restaurant (fast food, café, fine dining)
- Type of cuisine (French, Thai, Vegetarian)
The Dining Availability Response message contains a list of dinings available for a given sailing and for a select-
ed fare. For each dining the following information may be returned: Dining code; Dining status; Sitting; Meal
name; Meal times; and Marketing message.
OTA_CruiseFareAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Fare Availability message pair provides a listing of available fares for a selected voyage.
For some cruise lines, the voyage must be identified via the VoyageId; for others, the departure date and dura-
tion identify the sailing.
The guest count structure is used to communicate the number of guests that will be sailing. Although guest
transportation information is optional, a prudent practice is to enter the mode of transportation and gateway
city, because some fares have restrictions based on transportation.
The response message returns a list of available fares for which the traveler qualifies based upon the criteria
provided.
88
© 2013, OpenTravel Alliance. All rights reserved.
OTA_CruiseFastSellRQ
Message Pair Overview
The OpenTravel Cruise Fast Sell Request message requires the user to provide all mandatory sailing infor-
mation. Optionally, category, price program, package code and cabin information may be provided.
The Fast Sell message is a multipurpose request to access one of the following cruise provider functions:
1. Cabin hold (maximum of 4 cabins) when a cabin number is provided,
2. Cabin availability when a cabin number is not provided and a category is provided,
3. Category availability when neither cabin, nor category is specified in the request,
4. Fare availability when the fare code provided in the request is either incorrect for the sailing or not
available,
5. Package availability when the package is specified, but not available for the sailing.
The response is conditional upon inventory availability for the requested function:
- If the cabin is available, the response will be the cabin hold message (OTA_CruiseCabinHoldRS).
- If cabin is unavailable for hold, the response will be cabin availability (OTA_CruiseCabinAvailRS).
- If category is unavailable, the response will be category availability (OTA_CruiseCategoryAvailRS).
- If the fare is not available the response will be fare availability (OTA_CruiseFareAvailRS).
- If the sailing or package is not available, the response will be sailing (OTA_CruiseSailAvailRS) or pack-
age availability (OTA_CruisePkgAvailRS).
OTA_CruiseInfoRQ/RS
Message Pair Overview
The OpenTravel Cruise Information message pair provides miscellaneous information on cruise ship statistics,
embark/debark times, cruise policies, cruise line contacts, etc.
In the request message, the user can specify the type of information being requested by either a code or name.
Sailing information may be provided if the user wishes to see sailing-specific (e.g., cabin or category) details. By
providing the reservation ID, consumer advice for that reservation may be returned.
The response message returns miscellaneous structured cruise information (e.g., cruise ship characteristics, em-
bark/debark times, cruise policies and cruise line contacts).
OTA_CruiseItineraryDescRQ/RS
Message Pair Overview
The OpenTravel Cruise Itinerary Description message pair allows customers to request the detailed itinerary of a
specific sailing. The Cruise Itinerary Description request message can accept a reservation ID/ booking number
or a ship and sail date to retrieve the itinerary. The response message contains the detailed itinerary in the fol-
lowing formats:
- Every location the ship visits in its entire voyage is listed as a port on the itinerary.
- The departure date and time are listed for each port except the disembarkation port.
89
© 2013, OpenTravel Alliance. All rights reserved.
- The arrival date and time are listed for each port except the embarkation port.
- The port element can also specify “At Sea”, indicating a sailing period.
- Each port listed contains an indicator to specify whether the ship docks at that specific location. This
feature can be used to include scenic locations such as “The Great Barrier Reef” on the itinerary, even
though the ship does not dock at the location.
- Each port listed also contains an indicator to specify whether or not shore excursions exist at that loca-
tion.
OTA_CruisePaymentRQ/RS
Message Pair Overview
The OpenTravel Cruise Booking Payment message pair provides the user with the ability to submit payments for
an existing reservation without first retrieving the reservation. The user can specify the reservation ID for which
the payment is being submitted along with the details of the form of payment (e.g. credit card, voucher, etc.) and
the amount. Optionally, information about the agent making the payment on behalf of the customer may be pro-
vided.
The response message returns the status of each payment that was submitted.
OTA_CruisePkgAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Package Availability message pair is used to request information about the pre-cruise,
post-cruise, or the inclusive-cruise packages associated with a sailing. A cruise package is normally a stay in a
hotel for one or more days at the beginning or end of a cruise. The hotel is generally located near the port of em-
barkation or debarkation.
The response message contains a list of requested packages along with the associated pricing for these packages.
OTA_CruisePriceBookingRQ/RS
Message Pair Overview
The OpenTravel Cruise Price Booking message pair provides pricing for all components of a booking. For the
cruise pricing to be correct, all of the components to be purchased must be included in the Cruise Price Booking
request. This includes the sailing by using either the VoyageId or the ship and sail date depending on the cruise
line, the priced and berthed category, the fare code, the group code (when applicable), the air gateway, the pre
and/or post land packages, the shore excursions, and anything else the cruise line sells at the time of making a
reservation.
The response message returns the pricing breakdown by component for both the booking and the individual
travelers.
OTA_CruisePNR_UpdateNotifRQ/RS
Message Pair Overview
The OpenTravel Cruise PNR Update Notification message pair provide unsolicited messages originating from a
cruise line company to the GDS or travel partner. When a cruise booking is made, some travel partners may
cache a copy of the booking information in their local application systems, however, there may be occasions
90
© 2013, OpenTravel Alliance. All rights reserved.
where a cruise line makes changes to the booking in their system, which would cause the records to become non
synchronized.
This could be for a number of reasons, including: Change in departure time, direct communication from the cus-
tomer to the cruise line that bypasses the travel partner, change from waitlisted status, cancellation for non-
payment, reinstatement of a booking, etc.
This message pair provides a defined structure to push these unsolicited update messages to the travel partner,
and enable passenger record synchronization between the cruise line company and the travel partner:
- Precondition: A cruise booking by the travel partner exists, and the cruise line company has made
changes.
- Post-condition: The travel partner receives the change message.
OTA_CruiseSailAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Sailing Availability message pair provides a listing of available voyages for: a date range,
a specific geographic region and/or a specific ship code. Cruise vendors typically don’t restrict the returned list
of voyages to an exact request date, but will return sailings that fall within a time window around the requested
date. There are two common methods in the cruise industry of identifying a sailing. Some cruise lines return the
VoyageID, and other cruise lines only return the Departure Date and Duration to identify the sailing.
The Cruise Sailing Availability request message requests sailing availability for a geographical region and a
specified datefor a specified number of passengers. Optional request information can include cruise lines and
ship codes. The request can be narrowed to request availability for a specific cruise line or specific ship.
The Cruise Sailing Availability response message contains sailing availability for 1 or multiple cruise lines for a
given region or shipon a date and duration range. For each sailing the following types of information may be
returned:
- Cruise line code, ship code, region code and status code
- Departure date, duration and port code
- Arrival date, duration and port code
- Voyage number and number of ports visited
- Maximum cabin occupancy and category location
- First and second dining services status
- Sailing indicators and free flow text
- Available modes of transportation
- Available currencies
- Cruise package information
- Registration information
This message contains similar information to a standard airline CRS or GDS sailing availability response mes-
sage.
91
© 2013, OpenTravel Alliance. All rights reserved.
OTA_CruiseShorexAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Shorex Availability message pair is used to request information about shore excursions
associated with a sailing. A shore excursion is normally a sightseeing tour, a shopping expedition or activity such
as snorkeling or horseback riding to be taken while the ship is visiting one of the ports of call on a cruise.
The Shorex Availability request message requests shore excursions for a given sailing and currency.
The Shorex Availability response message contains shore excursion packages that are available for the given sail-
ing/ports along with the associated pricing.
OTA_CruiseSpecialServiceAvailRQ/RS
Message Pair Overview
The OpenTravel Cruise Special Service Availability message pair allows a cruise vendor to offer special services
to their guests, in addition to offering the cruise sailing itself (often at no charge to the customer.)
These can be categorized as:
- Occasion (birthday, anniversary, back-to-back cruise, etc.)
- Special Service (wheelchair, special dietary needs, etc.)
- Language (language translation needs)
Additional categories can be defined by the cruise vendors and special services are offered/selected at either a
passenger or cabin level. The Cruise Special Service Availability Request message queries all the special services
available for a given sailing/reservation IDor details for a specific special service. The Cruise Special Service
Availability Response message returns information about which special service packages are available for the
given sailing.
92
© 2013, OpenTravel Alliance. All rights reserved.
DESTINATION ACTIVITY MESSAGES
Messages Overview
Travelers often want localized experiences during their vacation or journey and these may include taking guided
tours, attending performances or shows, and buying tickets to local attractions. All these products, while varying
greatly in makeup, are collectively termed here as “Destination Activities.”
The purpose of these messages is to enable the electronic distribution and sale of this type of product by request-
ing the reservation functionality of a target system and making a reservation.
Future versions of this message may support availability requests, modification, and the transfer of descriptive
information, rates and inventory.
Messages List
- OTA_DestinationActivity.xsd
- OTA_DestActivityCapabilitiesRQ/RS
- OTA_DestActivityResRQ/RS
93
© 2013, OpenTravel Alliance. All rights reserved.
OTA_DestActivityCapabilitiesRQ/RS
Message Pair Overview
The OpenTravel Destination Activity Capabilities message pair enable a “seller” system to discover the capabili-
ties of a “target” system. Once the capabilities of a target system have been discovered, the seller system may
either alter its behavior in regards to selling that target product or choose not to offer that product range.
The Destination Activity Capabilities Request message sends a request for the functional capabilities of the tar-
get system so following messagessuch as the Destination Activity Reservation message
(OTA_DestActivityResRQ/RS)may be altered depending upon the target system's level of functionality.
The Destination Activity Capabilities Response message returns a set of data representing the available func-
tionality in the system, including:
- A MultipleItemsInd attribute that indicates if the target system supports receiving multiple items in one
reservation call, like a shopping cart. Some target reservation systems do not support receiving multiple
items in one reservation call, and in this case, if the seller system sells multiple products in its shopping
cart from the one target system, one reservation call per item must be sent.
- A CustSubAllocationInd attribute that indicates if the target system supports having a subset of the trav-
eler group utilized per item. For example, a family of four (husband, wife, two children) are making a
reservation and details for all four family members are sent. There are three items in the cart a family
ticket to an amusement park (which all four members are using), a hop-on/hop-off bus tour (again with
all four family members), and a museum ticket for only the husband and wife (and priced and sold as
two adults only).
If the CustSubAllocationInd is true, the target system supports this arrangement and all traveler details are sent
with a list of which travelers are utilizing a service specified per item. If the CustSubAllocationInd is false, the
target system does not support this behavior and the seller system must either send two separate reservations or
prohibit this functionality during a customer interaction.
A FullCustDetailsInd that indicates if all customer details are required (for example, if four travelers are speci-
fied then all four names must be supplied) or if only one contact name and associated information ID required.
If FullCustDetailInd is true, the seller system must supply all traveler details for any reservation and the seller
system has several options, including:
- Collecting all traveler details only when necessary when selling product for this type of target system,
- Collecting all traveler details all the time, or
- Electing not to sell product from this target system.
OTA_DestActivityResRQ/RS
Message Pair Overview
The OpenTravel Destination Activity Reservation message pair allows a reservation to be requested/made for a
destination activity. There is no requirement to determine availability prior to sending a reservation request as
travel agencies, or individual guests, may send a request to book a reservation from an internet site if all the in-
formation required for booking is known.
The Destination Activity Reservation Request message sends a request for a reservation to another system, and
the Destination Activity Reservation Response message returns the requested reservation if the request can be
processedor includes warnings from business processing rules or errors if the request did not succeed.
94
© 2013, OpenTravel Alliance. All rights reserved.
DYNAMIC PACKAGE MESSAGES
Messages Overview
The OpenTravel Dynamic Package messages use existing OpenTravel Air and Hotel message functionality in
combined messages that provide one central location for air and hotel searches to be run simultaneously. Rather
than sending a message for each component, a Dynamic Package message allows one request to handle multiple
component requests.
The Dynamic Package messages are functionally different from the existing OpenTravel Package messages in
that rather than operating on static packages with predetermined components, the Dynamic Package messages
allow the creation of travel packages with independent air, hotel and rental car selections. In addition, the
OpenTravel Dynamic Package messages support “package options” that may be added to a dynamic package as
either stand-alone products or included items for existing components. Examples of package options include
show tickets, amusement park tickets, airport transfers, meal plan vouchers, club passes and travel insurance.
In addition to dynamic package availability and booking, the Dynamic Package messages also provide the follow-
ing business functionality:
- Retrieving booked dynamic packages
- Modifying entire or components of booked dynamic packages
- Canceling entire or components of booked dynamic packages
- Trading partner notification of changes to dynamic package components
Messages List
- OTA_DynamicPkgCommonTypes.xsd
- OTA_DynamicPkgAvailRQ/RS
- OTA_DynamicPkgBookRQ/RS
- OTA_ReadRQ/OTA_DynamicPkgBookRS
- OTA_DynamicPkgModifyRQ/OTA_DynamicPkgBookRS
- OTA_CancelRQ/OTA_DynamicPkgBookRS
- OTA_DynamicPkgModifyNotifRQ/RS
OTA_DynamicPkgAvailRQ/RS
Message Pair Overview
The OpenTravel Dynamic Package Availability message pair is used to obtain availability for various components
of a dynamic package reservation. It can be used for the following functions:
- Component (Air, Hotel, Car, PackageOption) Availability
- Component (Air, Hotel, Car, PackageOption) Availability with pricing
- Pricing for selected un-priced flight pairs. (This is useful for determining round trip pricing for unpriced
outbound/return flights)
The Dynamic Package Availability Request message requests availability based on the following information:
- Origin / Destination cities
- Specified dates
95
© 2013, OpenTravel Alliance. All rights reserved.
- Number and types of passengers
The Dynamic Package Availability Response message contains availability for each requested component.
OTA_DynamicPkgBookRQ/RS
Message Pair Overview
The OpenTravel Dynamic Package Booking message pair is used to book a specific dynamic package for one or
more identified travelers. The message may contain pricing information in order that prices obtained from pre-
vious requests can be verified during the booking process. Typically, the result of a Dynamic Package Booking
message would be a confirmed reservation.
This message pair may also be used for confirming package prices before making a complete booking request,
reducing the number of pricing errors returned during a purchase process.
OTA_ReadRQ/OTA_DynamicPkgBookRS
Message Pair Overview
The OpenTravel Read (reservation) and Dynamic Package Book Response message pair is used to retrieve a pre-
viously booked package reservation for review.
OTA_DynamicPkgModifyRQ/ OTA_DynamicPkgBookRS
Message Pair Overview
The OpenTravel Dynamic Package (reservation) Modify message pair is used to modify an existing dynamic
package reservation, which may include changes to guest information, travel or accommodation arrangements.
OTA_CancelRQ/OTA_DynamicPkgBookRS
Message Pair Overview
The OpenTravel Cancel (reservation) Request and Dynamic Package Booking Response message pair is used to
cancel a dynamic package in its entirety. Once this message is successfully run, the entire package is canceled in
the supplier’s system.
Please note that either the Dynamic Package Booking Response (OTA_DynamicPkgBookRS) or the OpenTravel
Cancel (reservation) Response (OTA_CancelRS) messages may be used to confirm the cancellation of the pack-
age.
OTA_DynamicPkgModifyNotifRQ/RS
Message Pair Overview
The OpenTravel Dynamic Package Modify Notification message pair is used to notify a trading partner of modi-
fication(s) to a dynamic package and is commonly used to synchronize data between a supplier and its partner’s
system. This message pair is initiated by a supplier system to update partner systems with any changes that have
taken place in the partner’s packages, including flight changes, car rental notices (such as inventory limitations)
and hotel room modifications.
96
© 2013, OpenTravel Alliance. All rights reserved.
The Dynamic Package Modify Notification Request is a “push” message that provides the capability for a suppli-
er trading partner to send notifications of any changes made to another system (e.g., if a flight is canceled or
moved to a later time the endpoint system needs to be alerted to the change).
The Dynamic Package Modify Notification Response message is a simple message acknowledgment that may
include a booking reference number.
97
© 2013, OpenTravel Alliance. All rights reserved.
GOLF MESSAGES
Messages Overview
The OpenTravel Golf messages provide three separate request/response pairs of messages to support the func-
tionality of requesting data from another system for finding a golf course, inquiring as to availability, and book-
ing a tee time.
All message pairs assume a pull model, where the originating system requests a specific set of data (as agreed by
trading partners) and are "no-state", meaning that the originating system will initiate the transaction and expect
a response from the queried system. All message responses include the request identification and responses may
be returned in any order.
Messages List
- OTA_GolfCommonTypes.xsd
- OTA_GolfCourseAvailRQ/RS
- OTA_GolfFacilityInfoRQRS
- OTA_GolfRateRQRS
- OTA_GolfCourseResRQ/RS
- OTA_GolfCourseResModifyRQRS
- OTA_GolfCourseSearchRQ/RS
98
© 2013, OpenTravel Alliance. All rights reserved.
OTA_GolfCourseAvailRQ/RS
Message Pair Overview
The Golf Course Availability message pair provides an availability search for a golf course and golf course ameni-
ties with (optional) pricing returned.
The Golf Course Availability Request message sends a request for course availability to another system. All the
elements and attributes are optional, unless otherwise stated as required by a trading partner. This message is
used to request availability at a known single course for one or more potential tee times. The specific infor-
mation about the golfer or golfers is necessary in order to validate booking rules and set rates.
The Golf Course Availability Response message returns the requested set of data if the request has been pro-
cessed, or includes warnings from business processing rules or errors if the request did not succeed.
OTA_GolfFacilityInfoRQ/RS
Message Pair Overview
The Golf Facility Information message pair exchanges updated golf course facility information which is used to
keep trading partner database(s) and cache(s) current with golf supplier facility information.
Golf facility request information includes the ID and (optional) name of the golf course facility, which may be
repeated to request information about multiple courses.
The Golf Facility Information response returns detailed golf facility information for the specified facility ID(s).
Response information includes:
- Facility ID, name and associated facility (if the course is on a hotel property)
- Short and long descriptions (with optional club type)
- Contact information, including phone and website
- Multimedia, including images, descriptions and movies that describe the golf facility
- Facility features, including dress policy, golf pros, on facility dining and course designer
- Available amenities, including type, description, pricing and reservation information
- Guideline tee time pricing, including minimum, maximum and average
- Location information, including physical and geo-coding
- Hours of operation
- Course conditions, including an optional source name or URL
- Policy information
- Directions
- Course closures
- Course restrictions
- Course scorecard
Additional message functionality includes transaction processing directives that influenced search results, such
as display currency.
99
© 2013, OpenTravel Alliance. All rights reserved.
OTA_GolfRateRQ/RS
Message Pair Overview
The Golf Rate message pair provides a method for exchanging tee time rates.
Requested rate criteria includes:
- The name of a golf course
- A date or range of dates, including days of the week, used to filter rate results
- Applied discounts that may include promotions and corporate ID's for negotiated rates