SSRs (Special Service Requests) (2024)

• 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.

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.

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.

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.

Example

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 DOCASSR, 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.

Example

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 DOCOSSR, 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.

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.

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:<![CDATA[]]>

• 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.