Booking Traveler Information

While providers and suppliers typically include traveler information within their PNRs and equivalent booking records, in Universal API, traveler-related information is contained within the Universal Record level, rather than within the PNRs.

Universal API permits an unlimited number of booking travelers within a Universal Record. However, individual providers and suppliers may have limits on the number of travelers that they permit within their booking records.

Existing booking traveler information within a UR can be added, modified, or deleted through the Universal Record. The key attribute for each BookingTraveler child element is used to uniquely identify that instance of the element. When applicable, references to the PNR source are associated with BookingTraveler elements.

Booking traveler information can be automatically populated through a profile using the AppliedProfile child of UniversalRecord. See Universal Record Modify.

While all attributes are optional in the schema, some providers or suppliers may require specific attribute data to complete transactions.

Attribute Description

Key

A system-generated key associated with the traveler may be required for subsequent requests.

TravelerType

The Passenger Type Code (PTC) of the traveler.

Note: As a best practice, infant passengers should always follow an adult passenger in the booking. Refer to Passenger Type Code for more information.

Age

The age of the traveler.

Note:For certain providers, name can also be sent as a Name Remark. Some suppliers may also require the age to be sent in an additional SSR or OSI.

VIP

The traveler's VIP designation.

DOB

Date of birth. This attribute may be required for age-specific fares.

Note:For certain providers, DOB can also be sent as a Name Remark. Some suppliers may also require the date of birth to be sent in an additional SSR or OSI.

Gender

Some suppliers may require the traveler's gender to complete a booking.

Jet2 (LS) requires the traveler's gender in the booking request. Universal API maps the gender based on the name prefix. Uncertain prefixes are mapped to Male.

Reference Data is available for Accounting Remark Type codes. To obtain the Type code values, send ReferenceDataRetrieveReq TypeCode="PersonGenderType".

Nationality

Some suppliers may require the traveler's nationality to complete a booking. If nationality is required, it can be specified in BookingTraveler@Nationality or in a DOCS Passport SSR.

 

The following child elements are contained within BookingTraveler.

Child Element

Description

BookingTraveler
Name

First and last names are required. Middle names, prefixes, suffixes are optional.

Note: Only Latin characters are allowed as part of the name. Special characters such as á, ū, ß, Æ, Ø, etc. are not allowed.

DeliveryInfo

For air or rail segments, the street address for a printed ticket delivery.

Exceptions:

  • Galileo allows a maximum of 119 characters and spaces for an address. If this maximum is exceeded, the address is truncated, An error is NOT returned from Galileo.

PhoneNumber

Phone numbers associated with the booking traveler. Universal API does not limit the number of phone numbers.

In Air v33.0 and greater, additional values were allowed for PhoneNumber @Type; see Phone Number Types below for more information.

Exceptions:

  • RCS permits up to five phone numbers.

    Some ACH carriers require the area code to be separate in @AreaCode. Other carriers will parse the area code as part of the string in @Number.

Email

Email addresses associated with the booking traveler. Universal API does not limit the number of email addresses.

Email Type is accepted in Universal API, and is limited to values in the enumerated list.

Exceptions:

  • RCS permits a maximum of three email addresses (@EmailID). If a supplier supports a limited number of email addresses, RCS filters the request to the supplier's limit.

  • Most ACH suppliers permit a maximum of one email address (@EmailID).

Exceptions for Email Type:

When applicable, the following providers the Email Type map to OTA Code List Email Address Type (EAT):

  • ACH maps three types: personal (1.EAT), business (2.EAT), listserve (3.EAT). All other types become 'Other' in Universal API.

LoyaltyCard

The loyalty membership information for a traveler, such as frequent flyer or frequent guest memberships.

SSR

Air segments only. Special Services Requests (SSR), such as required assistance or meal preferences. Unlike OSIs, SSRs are associated to an individual traveler, not to a PNR.

SSRs are typically associated to a traveler during air booking.

NameRemark

Stores remarks for a specified traveler. Various providers or suppliers may require additional data for a traveler that can be passed in the Name Remark.

SeatAssignment

If applicable, indicates the seat assignment for a specific flight or rail segment.

EmergencyInfo

Emergency contact information for the traveler.

Address

The address of the traveler.

Reference Data is available for Address Type codes. To obtain the Type code values, send ReferenceDataRetrieveReq TypeCode="PostalAddressType".

DriversLicense

The traveler's driver's license number. This data is typically required for vehicle shopping or booking.

AppliedProfile

If applicable, the traveler's profile identifiers.

TravelComplianceData

Travel compliance requirements can be added or updated at the Booking Traveler level for:

  • Policy Compliance
  • Contract Compliance
  • Preferred Supplier

A maximum of two each of PolicyCompliance and ContractCompliance child elements are permitted. An unlimited number of PreferredSupplier elements are permitted.

TravelInfo

TravelInfo includes TravelPurpose and TripName attributes.

  • These travel details can be added when a booking (air, hotel, vehicle, rail, or passive) is created.
  • Travel details can also be added, modified, or deleted when a Universal Record is modified using the BookingTravelerInfo element (UniversalRecordModifyReq/UniversalModifyCmd/UniversalAdd or UniversalUpdate).
  • Trip Name can be used to search (UniversalRecordSearchReq/SearchCriteriaGroup/TravelerCriteria).
  • Travel details can be included in a Saved Trip (SavedTrip/BookingTraveler).
  • Travel details are local to Universal API and are not present in host systems.

 

PNR References

References for Booking Traveler data to PNR can be specified in the request or returned in the response for transactions that contain a Universal Record.

Requests

Specific provider locator information is added to a request using two attributes in the UniversalRecord schema to identify the provider and PNR locator code. For example:

<univ:UniversalRecordModifyReq

<univ:RecordIdentifier UniversalLocatorCode="AAAH07"

ProviderCode="1G" ProviderLocatorCode="R03JKY"/>

Two attributes identify the source of the Booking Traveler Data:

The presence of the RecordIdentifier ProviderCode and ProviderLocatorCode attributes indicates that all of the UR Modify command changes in that request are made at both the Universal Record level and the corresponding Provider Reservation level. If these attributes are not included in the request, the Booking Traveler data is processed only at the Universal Record level. Provider-specific updates can be made using the BookingTravelerInfo child of UniversalAdd (add) and UniversalUpdate (change/delete) in UniversalRecordModifyReq/UniversalModifyCmd. Universal API confirms that the request is valid, and sends back a validation error if the UR Modify commands to not meet the provider-specific changes criteria.

This functionality is currently available for 1G, 1V, and 1P only. ACH, RCS, and SDK providers are not currently supported for this functionality. ACH and RCS do not consistently return Booking Traveler data in their responses. Therefore, the relevant data is taken from request (and is not synchronized with the provider PNR). For SDK PNRs, tagging occurs using the programmatic Provider Reservation Info that was created by Universal API.

Responses

Certain Booking Traveler elements have ProviderReservationInfoRef children that indicate an association with a specific provider record locator (PNR). Data from individual Booking Traveler elements can be referenced back to the original PNR source for that data, which allows clients to store different name remarks for the same traveler from different provider reservations.

In the response, supported Booking Traveler elements are associated to the appropriate provider reservation reference in the responses for all Booking types (Air/Hotel/Vehicle/Passive) and Universal Record modification. Each ProviderReservationInfoRef element is associated to the primary Booking Traveler. ProviderReservationInfoRef is the provider reservation key used to associate the Booking Traveler information to the individual elements. The associated reference also applies to these elements for the primary Booking Traveler during Universal Record Retrieve and other transactions that retrieve and existing Universal Record, when the PNR data in the Universal Record is synchronized with the data in the provider PNR.

Error and Warning Messages

If the provider does not accept any email addresses or loyalty cards, no provider reservation reference is returned for BookingTraveler/Email or BookingTraveler/LoyaltyCard. A warning message is returned to indicate that a provider reservation reference does not exist: API validates if the UR Modify request is valid, and sends back a validation error if any of the UR Modify commands do not meet the criteria for provider-specific changes.

During a UR Modify command (Add, Update, or Delete), if RecordIdentifier @ProviderCode and @ProviderLocatorCode attributes are not provided, and provider-specific updates are requested to any PNR other than the first PNR in the Universal Record, a warning is returned: Add, Change or Deletion not performed. Please provide @ProviderCode and @LocatorCode record identifiers.

If RecordIdentifier @ProviderCode and @ProviderLocatorCode attributes are provided for non-provider-specific changes, an error is returned: Provider specific changes not supported. Please Provide provider Code and provider LocatorCode.

Errors may also be returned from the provider if formatting is incorrect.

Phone Number Types

In Air v32 and earlier, the following enumerations were allowed for PhoneNumber @Type:

In Air v33.0 and greater, these values along with alphabetic codes A-Z are allowed for Apollo (1G) and Galileo (1V). Note that Universal API converts to "None" any values other than those listed above or the alphabetic code corresponding to those values.

The table below notes the values that can be submitted in PhoneNumber @Type and the @Type returned in the response.

@Type sent in AirCreateReservation
Request/BookingTraveler/ PhoneNumber

@Type returned in AirCreateReservationRsp/
UniversalRecord/
BookingTraveler/
PhoneNumber

Business

Business

Email

Email

Fax

Fax

Home

Home

Hotel

Hotel

Mobile

Mobile

None

None

Other

Other

A

Agency

B

Business

C

None

D

None

E

Email

F

Fax

G

None

H

Hotel

I

None

J

None

K

None

L

None

M

Mobile

N

None

O

None

P

None

Q

None

R

Home

S

None

T

1G: Agency 1V: None

U

None

V

None

W

None

X

None

Y

None

Z

None