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.

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:

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:

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

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