SSRs (Special Service Requests)

A Special Service Request (SSR) is a bulletin sent straight to suppliers to communicate traveler preferences, special services needed by a traveler, or of a procedural requirement necessary of the carrier. SSRs are supported for Air Bookings and Track Bookings.

SSRs include information such as meal preference or special assistance required for the traveler. In addition, the SSR can send an alert message back to the agency or travel provider. SSRs can originate with the travel provider request for service from the carrier or from the carrier asking for information (like a ticket number) from the travel provider.

Because action must be taken by the carrier, there is usually a reply from them in the grade of the status lawmaking on the SSR (HK, Un, etc.)

A Special Service Request (SSR) can exist made in a PNR on behalf of one traveler, several travelers, or all travelers for specific segments or an unabridged itinerary. A unmarried traveler and/or single segment may have multiple SSRs assigned to it, but the same SSR cannot exist assigned to the same traveler/segment more than in one case.

Of import: SSRs require the carrier to take action, while OSIs are informational only and practice not typically require an activeness or response from the carrier. OSIs and SSRs are NOT interchangeable. An SSR should be used if possible; an OSI should be used just if there is no standardized SSR bachelor for the service needed.

SSR Codes via Reference Information

Check Reference Data for the latest SSR Codes.

Programmatic and Manual SSRs

SSRs tin either be Programmatic (automated) or Manual (non-automated). Programmatic SSRs employ a code recognized past the provider/supplier, while Manual SSRs exercise not have an associated programmatic lawmaking. Other Items must be entered equally a manual SSR.. Programmatic SSRs are associated to both an Air segment and a PNR (ProviderReservationInfoRef); Manual SSRs are associated only to a PNR.

Unassociated SSRs

Unassociated SSRs are SSRs that practise not have a passenger clan in the PNR. Unassociated SSRs are added to the SSR element in UniversalRecord.

For Worldspan, all SSRs have a traveler reference in the response, which means there are currently no Unassociated SSRs identified in Worldspan responses.

ClosedUnassociated SSRs when creating bookings or modifying Universal Records

  • When a reservation is created (*CreateReservationReq) or a Universal Record (UR) is modified (UniversalRecordModifyReq), SSRs tin can exist sent in the SSR element in the request. If the provider returns an SSR without a traveler identifier, Universal API returns the Unassociated SSR in the Universal Tape/SSR element in the response.

    When a Universal Record is retrieved, the SSR is returned in the offset booking traveler, unless the UR is synched with the provider. If the UR is synchronized, the SSR is returned at the Universal Record level.

  • Universal API validates @Carrier in UniversalRecord/SSR against a list of all the carriers in the air/passive segments sent in Air or PassiveCreateReservationReq or UniversalRecordModifyReq /AirAdd. If matched, @Carrier passed to the provider for the Universal Record-level SSR. If no match is found, the Carrier is not sent to the provider in the request. This functionality ensures Unassociated SSRs that apply to all carriers are correctly placed.

    Segment reference is not implemented for the SSR element at the Universal Record level. If a segment reference is included for a Universal Record-level SSR in a create or modify transaction, it is ignored by Universal API.

ClosedUnassociated SSRs and SDK providers

Travelport Universal API has not changed its current functionality for SSRs when creating a reservation with an SDK provider. These SSRs are added to the requested levels (first Booking Traveler, second Booking Traveler, any Booking Traveler, or UR/PNR level). A background passive reservation created with the addition of an SDK segment does not take any SSR.

ClosedUnassociated SSR descriptions

The following table shows Unassociated SSRs. All of the following Unassociated SSRs use to Galileo, Apollo, and SDK providers.

Note: For Worldspan, all SSRs have a traveler reference in the response, which means at that place are no Unassociated SSRs identified in Worldspan responses.

SSR Description Remarks

TKTL

Ticketing Time Limit

PCTC

Passenger Contact

FOID

Course of ID

FQTV

Frequent Traveler

FQTR

FQTV Redemption

FQTS

FQTV Condition

CLID

Corporate ID

GUAR

Guarantee Information (Payment Data)

EPAY

Electronic Payment

LIMO

SSR LIMO should not be tested since My Travelport advised non use EY (Etihad Airways) to exam LIMO SSR on test/ copy. EY is the but airline where LIMO SSR applies today.

DOCS

secure flight information (Passport)

Doctor SSRs (DOCO, DOCA and DOCS). Technically, these are Unassociated SSRs; however, the existing implementation of matching traveler name ensures the majority of DOC SSRs are not unassociated. The exception is when a traveler name has more than than 55 characters in the SSR text. Considering of truncation of that text, the SSR cannot be matched and is considered Unassociated and added to the UniversalRecord/SSR element in the response.

DOCO

other type of rider data (Visa)

DOCA

passenger address information

ClosedUnassociated group SSRs

Unassociated Group SSRs must be populated at Universal Record level in the response and associated with Grouping element using SSRRef@Key attribute. For instance, GRPF is an unassociated SSR in Worldspan; GRPS is an unassociated SSR in Galileo, Apollo, and Worldspan.

Calculation an SSR to a Booking

Supported SSRs can exist added to a booking through UniversalRecordModifyReq/UniversalModifyCmd/AirAdd/SSR. This includes all providers also every bit ACH carriers, but but if the specific carrier allows post-book modifications. In improver, if a specific ACH carrier allows a refund and/or exchange, SSRs can be added afterward booking through AirExchangeReq/SSRInfo/SSR.

If a carrier does not allow post-volume modifications, Universal API returns the warning bulletin "Carrier does not back up adding SSR." If the specific SSR is not supported by the carrier, the message "SSR type not supported past this carrier" is returned.

SSR Codes

Each SSR uses a four-character IATA lawmaking that specifies the type of service requested. These codes and their recommended use are pre-defined by IATA, however, not all suppliers or providers support the utilize of all SSR codes.

SSRs can be sent with or without boosted descriptive free text. Additional text may be required, optional, or prohibited, depending on the type of SSR. Besides, some providers or carriers may non support additional text for an SSR type, even if free text is permitted for that SSR past IATA standards.

Gratuitous text can be used to further ascertain a request. For example, two additional baggage items can be detailed in the free text. If ane passenger is traveling with two bicycles then the text can say "traveling with 2 bikes". If two passengers are traveling, and there are two bikes, and then one Wheel SSR can be assigned to each rider.

The post-obit SSR's are some of the most commonly used SSR'due south. Check Reference Data for the latest list of all SSR Codes.

Notes:

  • Seat SSRs are non supported, as a seat assignment tin can be requested with the booking.

ClosedEvidence SSR Codes

Status Code

Description

Free Text

Reply

DOCS

Passport/travel document information. Includes APIS data.

Required in specific format.

See details.

None. Condition remains 'NN'

DOCA

APIS rider residence address data.

Come across details.

None.

DOCO

APIS secondary document information.

Encounter details.

None.

CKIN

Associated with an activity related to passenger check-in, such as a asking for residency data.

E.g., Spanish resident data.

Personal Geography data is not included in responses.

BLND

Traveler is blind.

Optional.

Mandatory.

DEAF

Traveler is deafened.

Optional.

Mandatory.

WCHC

Wheelchair is needed -- traveler is completely immobile.

Optional.

Mandatory.

WCHR

Wheelchair is needed -- traveler can ascend/descend stairs.

Optional.

Mandatory.

TKNM

Manually entered ticket number for carrier notification.

Required, must include ticket number.

None.

Meal SSRs

AVML, BBML, BLML, CHML, DBML, FPML, GFML, HFML, HNML, KSML, LCML, LFML, LPML, LSML, , MOML, NLML, ORML, PRML, RVML, SFML, SPML, VGML, VLML

None, except SPML, which permits free text.

Typically returns 'KK'

INFT

Baby traveling in lap. Run across Babe SSR

Optional free text.

Mandatory to confirm or refuse

CHLD

Child traveling

Optional appointment of nascency. (No additional complimentary text allowed.)

Optional. Status may remain 'NN'

FQTU

Frequent traveler with upgrade and mileage accrual

Non supported by all carriers. Provider volition validate and neglect the SSR if not supported.

None.

GUAR

Not an IATA-standard SSR, just is supported in Gailleo but on guaranteed payment carriers.

Required.

Gratuitous text includes the credit carte, expiration appointment, and cardholder proper noun.

None.

FOID

Form of ID. Universal API supports all forms of ID, except Credit Card.

Mandatory

Driver'south License

Frequent Flier Carte du jour

Passport

National ID Card

Record Locator

Local ID

Carrier Ticket Number

Action lawmaking is mandatory but a respond will not be returned.

TWOV

Transit without visa

Segment reference and text are optional
CTCE, CTCM, CTCR

Client contact information for flight suspension or delay notifications.

If SSRs CTCE and CTCM are present in the itinerary, the airlines that have automated notification processes will notify the travellers straight of flying cancellations, changes, or delays.

  • CTCE = Passenger contact electronic mail address
  • CTCM = Passenger contact mobile phone number
  • CTCR = Passenger contact refused

SSRs for CTCE/CTCM should accept Booking Traveler Reference since they are associated to the passenger. Please add them inside Booking Traveler information.

See Rider Contact SSRs for Flight Interruptions

Optional simply tin outcome in ADM fees.

Customer can refuse to provide - use SSR Lawmaking CTCR

 If data is missing or not entered in the correct club of the SSR CTCM and CTCE structures, the arrangement will non accept the information and will reply with an error response.

Passenger Contact SSRs for Flight Interruptions

The SSRs CTCE and CTCM are used to contact customers in example of:

  • Astringent weather condition weather condition,
  • Growing congestion at airports and airspace
  • Irregular flight operations and disruptions

These SSRs tin be added in Profiles, Client Files, or WorldFiles, or in the PNR. Airlines will employ the contact information provided in the CTCE and CTCM SSRs to communicate to the client whatever operational notifications within the operational window. All Travelport points of sale support these Industry Standard SSRs for passenger email and mobile telephone:

  • CTCE = Rider contact email address
  • CTCM = Passenger contact mobile phone number
  • CTCR = Rider contact refused

ClosedBoosted details

If only CTCE is provided, the airline will message using e-mail.

  • If only CTCM is provided, the airline will bulletin using SMS/text (no phone calls).
  • If both CTCE and CTCM are provided, the airline will utilize e-mail when it is more than 24 hours before divergence and use SMS/text within 24 hours.
  • If more than one CTCE is provided for one passenger, the airline may select the terminal CTCE received assuming information technology to exist the near electric current.

These SSRs have defined structure and precise information that enables the airlines to provide operational notifications to the passengers such as flight cancellations, delays, changes, etc. It is highly recommended to include the SSRs CTCE and CTCM in the PNR.

SSR CTC (CTCM, CTCE and CTCR) Full general Rules and important information regarding user/customer impact

  • SSR CTC (CTCM, CTCE, and CTCR) are non-automated passenger name related (not-segment associated).
  • Apollo, Galileo, and Worldspan restrict segment select and require a carrier lawmaking in SSR CTC (CTCM, CTCE, and CTCR) entries.
  • The carrier code may be for a specific carrier or the generic carrier code YY.
  • In improver to calculation a carrier code in an SSR CTC entry, the action code HK1 must be entered.
  • For SSR CTCM, CTCE, and CTCR always name select regardless of how many passengers are in the PNR.
  • Profiles, Client Files, and World Files need to be updated with SSRs CTCM and CTCE.

Prior to moving an SSR CTC with a YY (generic) carrier code from a Y line in Apollo Pro-Files or Galileo Client Files, flight segment(due south) must exist sold. The alternative is to store SSR CTC items with a YY (generic) carrier code equally an O line. When the generic carrier code YY is used in an SSR CTC entry, Apollo, Galileo, and Worldspan will internally examine the itinerary and create an SSR CTC item for each air carrier in the PNR. Because SSR CTC detail(southward) with a YY (generic) carrier code are used internally to create a split up SSR CTC for each carrier lawmaking present in the itinerary, the SSR CTC entry with YY volition not exist stored in the PNR.

  • Apollo, Galileo, and Worldspan allow multiple SSRs CTCM and CTCE for the same passenger/name in the PNR.
  • The SSR CTCR should just be used if the passenger chooses non to provide an electronic mail or a mobile phone number for Irregular Operations (IROP); flight cancellations, delays, changes, etc., contact purposes.

Apollo and Galileo only: When a segment for a new carrier is added to an existing PNR/BF that contains previously stored SSR CTC items, neither Apollo nor Galileo volition automatically create a new SSR CTC detail or send a TTY-OUT for the newly added carrier into the itinerary. The user volition be required to add the SSR CTC detail with the new carrier code or apply the YY (generic) carrier code which volition send to all existing and new airlines in the itinerary.

The limit for non-automated (Manual) SSRs is 127 characters.

CTCE Email Format

When formatting emails for CTCE, follow these rules:

  • Use // (double slash) in identify of @ (at sign)

  • Apply ".." (double dot) in place of "_" (underscore)

  • Employ "./" in place of a "-" in email addresses

For example, instead of John_Doe-Jr@travelport.com, format the email address John..Doe./Jr//travelport.com

Split Function

No changes will exist made in the PNR Separate process that currently moves SSR items for applicable name(s) when a PNR Divide is performed. When a PNR Dissever is performed SSR CTC (CTCM, CTCE and/or CTCR) items will be moved to divided PNRs in the SSR format.

Proper noun deletes/changes

In line with current non-automated (Transmission) SSR processing, Apollo, Galileo and Worldspan shall ensure that when a name is deleted or changed all related SSR DOC (DOCA, DOCO and DOCS) items are canceled.

Notation: In the case of a name alter, a new SSR CTC detail must be created.

Document SSRs

DOC SSRs (DOCA, DOCS, and DOCO) were previously automated (Programmatic), just were modified to non-automated (Manual) SSRs. Previously, they were associated with the Air segment, but are now associated to the PNR in the transaction response (ProviderReservationInfoRef).

Closed DOCS SSR

For the DOCS SSR, the Travel document type, Travel Document Issuing Country/State, and Travel Document Number fields must all be entered or none of them should be entered.

ClosedExample

SSR Type="DOCS"
FreeText="P/GB/S12345678/GB/12JUN63/1000/23OCT14/SMITH/JOHN"
Carrier="Xx"/>

In this instance, the FreeText values are:

  • P = Passport (Travel Document Type)
  • GB = Issuing State
  • 123456788 = Document Number
  • GB = Passenger Nationality
  • 12JUN63 = Engagement of Birth
  • Grand = Male gender
  • 23OCT14 = Death appointment of passport (Travel Document Type)
  • SMITH = Concluding Name
  • JOHN = First Name

Closed DOCA SSR

For the DOCA SSR, if the Address type is specified (R-Residential or D-Destination address), then the country of the accost should besides be specified and vice versa. Only one DOCA SSR should exist included per PNR when all travelers have the same R-Residential or D-Destination accost. If all travelers in the PNR do non have the same R-Residential or D-Destination address, then name select must be utilized within the DOCA request.

ClosedInstance

SSR Blazon="DOCA" FreeText="HK1/R/US/1600 SMITH ST/HOUSTON/TX/77001" Carrier="20"

/R/ designates residence and /US/ designates the country code of the address. The format of the accost after the country lawmaking is to delimit each address element with a "/".

Closed DOCO SSR

For the DOCO SSR, the requirements for visa information vary by provider. For all providers, the Supplementary Travel Information document type (e.one thousand., Visa) and Supplementary Travel Information Number (e.g., Visa Number) fields must both be entered, or neither should be entered.

Certificate types of 'R': Redress Number and 'K': Known Traveler Number tin can exist input in the DOCO SSR with their respective number. Both a Redress Number or Known Traveler Number type always needs a supplementary Travel Information Number.

In a DOCO SSR, a Redress Number must be accompanied by a DOCS SSR for the traveler.

In all cases, validation is performed by the provider.

The following table lists the visa data that tin can be sent in Universal API as gratis-course text for SSR DOCO, and which fields are required in Galileo, and ACH.

ClosedCase

SSR Type="DOCO" HK1//V/1234567/LONDON/14MAR07/USA-1SMITH/JOHNMR Carrier="Twenty"

/V/ designates a Visa every bit the alternate certificate, London is the place of event, and DDMMMYY is the date of outcome.

Some providers have different requirements for DOCO data.

SSR Type="DOCO" Status="HK" FreeText="1//Thousand/123456789///-1.one" Carrier="BA"/>

/Thousand/ designates a Known Traveler number every bit the alternating document.

Per TSA the following guidelines utilize to the Known Traveler number every bit of September 2020 (subject to alter):

  • When issued with Global Entry, Nexus, or Sentri the number volition begin with 98 and be a total of 9 digits in length.
  • When by TSA the lawmaking will begin with TT followed by 7 digits.
  • When U.S. Armed forces, the 10 digit DoD ID number tin exist utilized.

Provider

Place of Nascence

Visa Number

Identify of Issue

Date of Issue

Country to which visa applies

Passenger Name

Expiration Date

Galileo

No

Yes

Yes

Yes

Aye

No

Yeah (equally of Jan 1 2020)

Apollo

Yes

Yes

Yes

Yeah

Yes

No

Yes (as of Jan ane 2020)

ACH

No

No

No

No

No

No

Yes

Worldspan

Aye

Yep

Yes

Aye

Yes

Yes

Yes (as of January i 2020)

Continuation SSRs

The industry standard for all SSRs is 69 characters. If an SSR exceeds this length, providers utilise a continuation SSR to send the excess text. Release 17.2 resolved an upshot in Worldspan (1P) in which Universal API was not properly returning text from continuation SSRs. For all schema versions, continuation SSRs will be returned when applicable. Continuation SSRs are identified past iii backslashes (\\\) afterward the initial SSR. Users can besides create SSRs longer than 69 characters, which will exist converted to continuation SSRs every bit necessary.

This affects all transactions that return a Universal Record, including air, car, hotel, and rail booking responses, and the Universal Record modify, import, search, and recollect responses.

Notation: Continuation SSRs are non supported for 1G/1V/ACH/RCS.

SSR Status Codes

SSRs take status codes to indicate their current condition in the fulfillment process. For case:

<com:SSR Blazon="DOCS" Status="HK" Carrier="XX" FreeText="P/Us/1234567/United states/25Jan85/Thou/23OCT17/Lastname/Firstname"/>

Status Code

Description

NN

SSR has been requested.

PN

SSR is awaiting confirmation.

United nations

Supplier (carrier) is unable to fulfill the request. The SSR in this instance will remain in the PNR as show that the service was requested and declined.

HK

SSR has been confirmed.

other

A carrier may send a different condition or choose not to respond to an SSR with an HK message, which means that the SSR status will e'er remain as 'NN'. This status is allowed on some SSRs with the assumption that the supplier has received the bulletin, and that the service volition exist provided.

Exceptions

ClosedGalileo

For Galileo, if the required fields are not sent in the SSR, an error response is returned in the book response.

Automatic Suspend SSR for AUX: DA-884 advises that a cusotmer tin can request the activation of TVPT Automatically Appending the SSR data for AUX at time of booking.

ClosedApollo

Closed Infant SSR

When an infant is non occupying a seat, add "an baby proper noun field" which follows the parent. The rider blazon is INF and the data of birth is required. That volition cause the Apollo GDS to associate an Baby SSR item to the adult. For case, in terminal: SSRINFTDLNN01 DTWATL 1365X 24MAY-1SNOW/JOHNMR.SNOW/TIM 24JAN16 (TIM is the infant)

Because of the previous sample, the airline will know who is holding the baby. The SSR DOCS item is and then entered every bit normal with the addition of an "I" after the gender.

Example for Universal API:

<com:SSR Key="2" Blazon="DOCS" Condition="HK" Carrier="XX" FreeText="///The states/24JAN16/MI//Snow/Tim"/>

If traveling internationally, even if the infant cannot yet walk or talk, she needs a passport.

<com:SSR Key="2" Type="DOCS" Status="HK" Carrier="XX" FreeText="P/US/ S12345678/Usa/24JAN16/MI/01JAN26/Snow/Tim"/>

ClosedInfant SSR Sample

<lather:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<univ:AirCreateReservationReq RetrieveProviderReservationDetails="truthful" TargetBranch="123" AuthorizedBy="Test" Version="0" RetainReservation="Both" xmlns:univ="http://www.travelport.com/schema/universal_v36_0">

<com:BillingPointOfSaleInfo OriginApplication="UAPI" xmlns:com="http://www.travelport.com/schema/common_v36_0"/>

<com:BookingTraveler Key="TuJJbrVu4hG1/9LlYIhwmw==" TravelerType="ADT" xmlns:com="http://www.travelport.com/schema/common_v36_0">

<com:BookingTravelerName Prefix="Mr" First="John" Final="Snowfall"/>

<com:PhoneNumber Central="1005359" CountryCode="011" Location="MCI" Number="123-456-7890" AreaCode="816" Type="Home" Text="Solar day"/>

<com:Email Type="Home" EmailID="jtestora@travelport.com"/>

<com:SSR Cardinal="1" Type="DOCS" Status="HK" Carrier="XX" FreeText="P/CA/F12345466/US/04JAN80/Thou/01JAN14/Snow/JohnMr"/>

<com:Address>

<com:AddressName>John Snow</com:AddressName>

<com:Street>335 East Primary</com:Street>

<com:Street>Apt 5B</com:Street>

<com:Urban center>Liberty</com:Urban center>

<com:Land>MO</com:Country>

<com:PostalCode>64153</com:PostalCode>

<com:Country>US</com:Country>

</com:Address>

</com:BookingTraveler>

<com:BookingTraveler Key="cxzQwd==" TravelerType="INF" DOB="2016-01-24" Gender="M" xmlns:com="http://www.travelport.com/schema/common_v36_0">

<com:BookingTravelerName First="Tim" Last="Snow"/>

<com:SSR Key="2" Type="DOCS" Status="HK" Carrier="YY" FreeText="///Us/24JAN16/MI//Snow/Tim"/>

</com:BookingTraveler>

<com:BookingTraveler Fundamental="TuJJbrVu4hG1/9LlY==" TravelerType="ADT" xmlns:com="http://world wide web.travelport.com/schema/common_v36_0">

<com:BookingTravelerName Prefix="Ms" Starting time="Marie" Last="Tilman"/>

<com:PhoneNumber Key="1009" Location="MCI" Number="816-111-2222" AreaCode="816" Blazon="Home" Text="Solar day"/>

<com:Email Type="Home" EmailID="maire@exam.com"/>

<com:SSR Central="three" Type="DOCS" Status="HK" Carrier="YY" FreeText="P/US/F1234567/US/09JUN85/Grand/01JAN15/Tilman/MarieMs"/>

</com:BookingTraveler>

Apollo supports:

  • Input of DOCO fields during AirCreateReservationReq. Nevertheless, all DOCO request(s) must exist accompanied by an associated DOCS request, or the HOST returns an error.
  • Generation of DOCS fields during the AirCreateReservationRsp.
  • Generation of DOCA fields during the AirCreateReservationRsp.

ClosedWorldspan

For Worldspan, all SSRs take a traveler reference in the response, which ways there are currently no Unassociated SSRs identified in Worldspan responses.

On Worldspan , when processing an Air Create of certain (ticketless) carriers:

  • The validation that the presence of SSR OTHS (other miscellaneous data) is removed, and a double End Transact (ET) is performed.
  • A alarm is returned in the AirCreateReservationRsp: "INCLUDE FOP IN SSR FOR TKLESS PYMT SEE >INFO TKTLESSPAY(OR GO USERS SELECT TICKETLESS PAYMENT SCRIPT FROM THE PNR TAB ¬ND TL/TKTG¬"

ClosedACH

  • ACH carriers vary in their support for SSRs.

  • For ACH, if the minimum required information is non sent in the SSR, the SSR is ignored and a warning message is returned.

  • ACH does not support unassociated SSRs.

  • For information on carrier-specific mandatory data, such as Advanced Rider Information, contact the carrier directly or visit their website.

ClosedRCS

  • RCS filters out whatsoever SSRs information that a provider does not accept. If the SSR is supported by the provider and is returned in the response, a ProviderReservationInfoRef fundamental is assigned.

  • Amtrak does not back up whatever SSRs.

  • SNCF includes the SSR in the response if it is accepted. A request for WCHR is returned as WCHC because it is the code closest to what they back up. The text in the response further defines what is supported. SNCF offers additional aid to PRM (Persons with Reduced Mobility) travelers at all stations, however the verbal type of assistance can vary by station. SNCF must exist contacted directly as the alert text explains.