SSRs (Special Service Requests)

A Special Service Request (SSR) is a message sent directly 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 Rail 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 asking 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 form of the status code on the SSR (HK, UN, etc.)

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

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

SSR Codes via Reference Data

Check Reference Data for the latest SSR Codes.

Programmatic and Manual SSRs

SSRs can either be Programmatic (automated) or Manual (non-automated). Programmatic SSRs use a code recognized by the provider/supplier, while Manual SSRs do not have an associated programmatic code. Other Items must be entered as 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 do not have a passenger association 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.

  • When a reservation is created (*CreateReservationReq) or a Universal Record (UR) is modified (UniversalRecordModifyReq), SSRs can be 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 Record/SSR element in the response.

    When a Universal Record is retrieved, the SSR is returned in the first 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.

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 have any SSR.

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

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

SSR Description Remarks

TKTL

Ticketing Time Limit

 

PCTC

Passenger Contact

 

FOID

Form of ID

 

FQTV

Frequent Traveler

 

FQTR

FQTV Redemption

 

FQTS

FQTV Status

 

CLID

Corporate ID

 

GUAR

Guarantee Information (Payment Data)

 

EPAY

Electronic Payment

 

LIMO

 

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

DOCS

secure flight data (Passport)

DOC 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 55 characters in the SSR text. Because 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 passenger data (Visa)

DOCA

passenger address information

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

Adding an SSR to a Booking

Supported SSRs can be added to a booking through UniversalRecordModifyReq/UniversalModifyCmd/AirAdd/SSR. This includes all providers as well as ACH carriers, but only if the specific carrier allows post-book modifications. In addition, if a specific ACH carrier allows a refund and/or exchange, SSRs can be added after booking through AirExchangeReq/SSRInfo/SSR.

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

SSR Codes

Each SSR uses a four-character IATA code 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 use of all SSR codes.

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

Free text can be used to further define a request. For example, two additional baggage items can be detailed in the free text. If one 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, then one BIKE SSR can be assigned to each passenger.

The following SSR’s are some of the most commonly used SSR’s. Check Reference Data for the latest list of all SSR Codes.

Notes:

 

Status Code

Description

Free Text

Reply

DOCS

Passport/travel document information. Includes APIS data.

Required in specific format.

See details.

None. Status remains 'NN'

DOCA

APIS passenger residence address information.

See details.

None.

DOCO

APIS secondary document information.

See details.

None.

CKIN

Associated with an activity related to passenger check-in, such as a request 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 deaf.

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

Infant traveling in lap. See Infant SSR

Optional free text. 

Mandatory to confirm or decline

CHLD

Child traveling

Optional date of birth. (No additional free text allowed.)

Optional. Status may remain 'NN'

FQTU

Frequent traveler with upgrade and mileage accrual

Not supported by all carriers. Provider will validate and fail the SSR if not supported.

None.

 

GUAR

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

Required.

Free text includes the credit card, expiration date, and cardholder name.

None.

FOID

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

Mandatory

Driver's License

Frequent Flier Card

Passport

National ID Card

Record Locator

Local ID

Carrier Ticket Number

Action code is mandatory but a reply will not be returned.

TWOV  

Transit without visa

Segment reference and text are optional

 
CTCE, CTCM, CTCR

Customer contact information for flight interruption or delay notifications.

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

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

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

See Passenger Contact SSRs for Flight Interruptions

Optional but can result in ADM fees.

Customer can refuse to provide - use SSR Code CTCR

 If data is missing or not entered in the correct order of the SSR CTCM and CTCE structures, the system will not accept the data and will respond with an error response.

Passenger Contact SSRs for Flight Interruptions

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

These SSRs can be added in Profiles, Client Files, or WorldFiles, or in the PNR. Airlines will use the contact information provided in the CTCE and CTCM SSRs to communicate to the customer any operational notifications within the operational window. All Travelport points of sale support these Industry Standard SSRs for passenger e-mail and mobile phone:

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

  • If only CTCM is provided, the airline will message using SMS/text (no phone calls).
  • If both CTCE and CTCM are provided, the airline will use e-mail when it is more than 24 hours before departure and use SMS/text within 24 hours.
  • If more than one CTCE is provided for one passenger, the airline may select the last CTCE received assuming it to be the most 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) General Rules and important information regarding user/customer impact

  • SSR CTC (CTCM, CTCE, and CTCR) are non-automated passenger name related (non-segment associated).
  • Apollo, Galileo, and Worldspan restrict segment select and require a carrier code in SSR CTC (CTCM, CTCE, and CTCR) entries.
  • The carrier code may be for a specific carrier or the generic carrier code YY.
  • In addition to adding 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(s) must be sold. The alternative is to store SSR CTC items with a YY (generic) carrier code as 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 item(s) with a YY (generic) carrier code are used internally to create a separate SSR CTC for each carrier code present in the itinerary, the SSR CTC entry with YY will not be 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 only be used if the passenger chooses not to provide an e-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 will automatically create a new SSR CTC item or send a TTY-OUT for the newly added carrier into the itinerary. The user will be required to add the SSR CTC item with the new carrier code or use the YY (generic) carrier code which will 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 place of @ (at sign)

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

  • Use "./" 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

Divide Function

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

Name deletes/changes

In line with current non-automated (Manual) 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.

Note: In the case of a name change, a new SSR CTC item must be created.

Document SSRs

DOC SSRs (DOCA, DOCS, and DOCO) were previously automated (Programmatic), but 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).

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.

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

In this example, the FreeText values are:

  • P = Passport (Travel Document Type)
  • GB = Issuing Country
  • 123456788 = Document Number
  • GB = Passenger Nationality
  • 12JUN63 = Date of Birth
  • M = Male gender
  • 23OCT14 = Expiry date of passport (Travel Document Type)
  • SMITH = Last Name
  • JOHN = First Name

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

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

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

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

Document types of 'R': Redress Number and 'K': Known Traveler Number can be 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 information that can be sent in Universal API as free-form text for SSR DOCO, and which fields are required in Galileo, and ACH.

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

/V/ designates a Visa as the alternate document, London is the place of issue, and DDMMMYY is the date of issue.

Some providers have different requirements for DOCO data.

 

SSR Type="DOCO" Status="HK" FreeText="1//K/123456789///-1.1" Carrier="BA"/>

/K/ designates a Known Traveler number as the alternate document.

Per TSA the following guidelines apply to the Known Traveler number as of September 2020 (subject to change):

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

Provider

Place of Birth

Visa Number

Place of Issue

Date of Issue

Country to which visa applies

Passenger Name

Expiration Date

Galileo

No

Yes

Yes

Yes

Yes

No

Yes (as of Jan 1 2020)

Apollo

Yes

Yes

Yes

Yes

Yes

No

Yes (as of Jan 1 2020)

ACH

No

No

No

No

No

No

Yes

Worldspan

Yes

Yes

Yes

Yes

Yes

Yes

Yes (as of Jan 1 2020)

Continuation SSRs

The industry standard for all SSRs is 69 characters. If an SSR exceeds this length, providers use a continuation SSR to send the excess text. Release 17.2 resolved an issue 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 by three backslashes (\\\) after the initial SSR. Users can also create SSRs longer than 69 characters, which will be converted to continuation SSRs as 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 retrieve responses.

Note: Continuation SSRs are not supported for 1G/1V/ACH/RCS.

SSR Status Codes

SSRs have status codes to indicate their current status in the fulfillment process. For example:

<com:SSR Type="DOCS" Status="HK" Carrier="XX" FreeText="P/US/1234567/US/25Jan85/M/23OCT17/Lastname/Firstname"/>

Status Code

Description

NN

SSR has been requested.

PN

SSR is pending confirmation.

UN

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

HK

SSR has been confirmed.

other

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

Exceptions

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

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

When an infant is not occupying a seat, add "an infant name field" which follows the parent. The passenger type is INF and the data of birth is required. That will cause the Apollo GDS to associate an Infant SSR item to the adult. For example, 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 infant. The SSR DOCS item is then entered as normal with the addition of an “I” after the gender.

Example for Universal API:

<com:SSR Key="2" Type="DOCS" Status="HK" Carrier="XX" FreeText="///US/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/US/24JAN16/MI/01JAN26/Snow/Tim"/>

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

<soap:Body>

<univ:AirCreateReservationReq RetrieveProviderReservationDetails="true" 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" Last="Snow"/>

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

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

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

<com:Address>

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

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

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

<com:City>Liberty</com:City>

<com:State>MO</com:State>

<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 Key="TuJJbrVu4hG1/9LlY==" TravelerType="ADT" xmlns:com="http://www.travelport.com/schema/common_v36_0">

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

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

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

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

</com:BookingTraveler>

 

Apollo supports:

  • Input of DOCO fields during AirCreateReservationReq. However, all DOCO request(s) must be 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.

For Worldspan, all SSRs have a traveler reference in the response, which means 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 information) is removed, and a double End Transact (ET) is performed.
  • A warning 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¬"

  • ACH carriers vary in their support for SSRs.

  • For ACH, if the minimum required data is not 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 Passenger Information, contact the carrier directly or visit their website.

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

  • Amtrak does not support any 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 support. The text in the response further defines what is supported. SNCF offers additional assistance to PRM (Persons with Reduced Mobility) travelers at all stations, however the exact type of assistance can vary by station. SNCF must be contacted directly as the alert text explains.