Air Booking with SSRs

A Special Service Request (SSR) is a message sent directly to suppliers to communicate traveler preferences, special services needed by a traveler, or a procedural requirement necessary for the carrier. SSRs are used for air segments only.

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.

See Special Service Requests (SSRs) for details.

Schema

Located in Universal.xsd:

• AirCreateReservationReq
• AirCreateReservationRsp

How To

1. Include the minimum required information for creating an air booking.

2. Include one or more SSRs using AirCreateReservationReq/BookingTraveler/SSR. Unlike OSIs, SSRs are assigned to individual travelers within a booking, not generically to the entire booking.

3. The response returns an Air Booking with SSR information located in AirCreateReservationRsp/UniversalRecord/BookingTraveler/SSR.

   If an SSR fails, the booking does not fail. However, a warning message is returned.

4. A status code is associated to each SSR. Depending on the type of SSR, a response from the provider is either mandatory, optional, or not expected.

Prior to Universal API Release 20.3.3, if the @SSRFreeText was not in the booking and/or fulfillment request, that information would not return in the response message, and potentially the booking would fail. After the 20.3.3 release, Universal API automatically adds the mandatory @SSRFreeText for the ancillary in the booking so that the ancillary is booked successfully. This results in a reduced risk of ancillary book requests from being rejected. For example, if an Air Create Reservation request contains an ancillary (e.g. baggage) with an Airline Code and Service Sub-Code, but no SSR Free Text, Universal API automatically appends the mandatory SSR to the booking. Release 20.3

• If the request contains SSR free text, it passes the value.
• If the request is missing SSR text:
  • For booking and fulfillment, if the request contains AirlineCode and ServiceSubCode values, but no SSR free text, Universal API adds text from cached data.
  • If SSR free text is null, and Universal API does not have an associated value in cached data that correlates with AirlineCode, ServiceSubcode the request passes blank (null) data.
  • The response populates missing SSR text from the request to add in the fee text field in the response (if text is available) to accompany the explanation.
• If Universal API appends an SSRFreeText value to a request, the appended SSRFreeText returns in the booking or fulfilment response.
  • As of this release, an appended SSR Free Text value is sent in the response in the OptionalService @SSRFreeText
  • /SSR @FreeText also returns in secondary SSRs like XBAG, in /UniversalRecord/BookingTraveler.
• XPath: In Universal.xsd

  • OptionalServices/OptionalService @SSRFreeText is automatically appended in:

    • AirCreateReservationReq/AirPricingSolution/
    • AirMerchandisingFulfillmentReq/

  • And returns in UniversalRecord/AirReservation/OptionalServices/OptionalService @SSRFreeText in:

    • AirCreateReservationRsp/
    • AirMerchandisingFulfillmentRsp/

  • /SSR @FreeText also returns in secondary SSRs like XBAG. For example,

    • AirCreateReservationRsp/UniversalRecord/BookingTraveler/SSR @FreeText
    • AirMerchandisingFulfillmentRsp/UniversalRecord/BookingTraveler/SSR @FreeText

Exceptions

Apollo

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.