Remarks and SSRs

The JSON APIs support adding several types of remarks and special service requests (SSRs) during the initial booking workflow as well as after the PNR is created.

Some remarks, such as traveler and client delivery remarks, are sent in the Add Traveler step in the initial booking workflow. Other remarks are sent in an Add Remarks payload either during the initial booking workflow, or you can add them to an existing PNR. Some types of remarks are returned in the PNR retrieve while others are not.

This topic provides the endpoint for remarks sent in both Add Traveler and Add Remarks, notes whether the PNR retrieve returns that remark, and provides example requests.

In this topic:

About SSRs and Remarks

A Special Service Request (SSR) is a message sent directly to carriers to communicate traveler preferences, special services needed by a traveler, or a procedural requirement necessary of the carrier. SSRs include information such as meal preference or special assistance required for the traveler. Because action must be taken by the carrier, there is usually a reply in the form of the status code on the SSR (HK, UN, etc.)

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 carriers support the use of all SSR codes. You can download the Reference Data files linked on the Tools page for a list of all SSR codes. The JSON APIs do not send or return the IATA codes for SSRs; instead, they send specific information during booking and/or ticketing to the carrier, which transforms the remark into the appropriate SSR as needed.

PNRs support additional types of remarks. Other Service Information (OSI) requests are messages sent directly to the supplier to communicate traveler preferences or requirements. OSIs are typically used to notify a supplier of special circumstances. Unlike SSRs, OSIs are informational only and do not require the supplier to take action.

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.

Remarks Requested in Add Traveler Payload

POST Request and Response

Several types of remarks can be added as part of the Add Traveler step during the initial booking workflow:

  1. Create workbench.

  2. Add offer.

  3. Add traveler, including required data for remark to create for that traveler.

  4. Commit workbench.

Most traveler remarks must be added during the initial booking and cannot be added to the PNR later. Some remark addition/deletions are supported post-booking; see Modifying a PNR for details.

For all requests in this section, send the POST request as follows:

POST

book/traveler/reservationworkbench/{workbenchID}/travelers

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/9/air/

Production https://api.travelport.com/9/air/

The Add Traveler response returns a confirmation identifier per the following example.

The response returns a confirmation identifier.

{
    "TravelerResponse": {
        "Traveler": {
            "@type": "TravelerIdentifier"
        },
        "Identifier": {
            "value": "f7bc47ac-2e59-4589-94d9-c9695804b9d0"
        }
    }
}

Traveler remark (SSR DOCO and DOCS)

To add a traveler remark such as passport or visa information, send the TravelDocument object in the Traveler object when you add the traveler. Passport details are converted to SSR DOCS. Visa, redress number, and known traveler details are converted to SSR DOCO. If multiple travel documents are needed, include additional instances of TravelDocument.

This type of remark can be modified for an existing PNR, and added to an existing PNR.

When adding visa information for a DOCO SSR, both issueDate and expireDate are required. Date formats are the Travelport JSON API standard YYYY-MM-DD. When visa details are sent, AirReservation creates the necessary SSR DOCO format per IATA standards. No special formatting is required, and the information is automatically populated for the PNR.
NDC supports only passport information for traveler documents: Send TravelDocument/docType Passport, which is converted to SSR DOCS P.
GDS supports passport information per above plus TravelDocument/docType values of Visa (SSR DOCO V), Redress (SSR DOCO R), and KnownTraveler (SSR DOCO K).

All traveler information added is returned in the commit step and in the PNR retrieve.

Include the following TravelDocument object in the Add Traveler payload to be converted to SSR DOCS. 

"TravelDocument": [
         {
           "@type": "TravelDocument",
           "docNumber": "H294F4",
           "docType": "Passport",
           "expireDate": "2027-02-22",
           "issueDate": "2020-05-20",
           "issueCountry": "IND",
           "birthDate": "1980-11-22",
           "Gender": "Male",
           "PersonName": {
               "@type": "PersonName",
               "Given": "PHILL",
               "Middle": "Mr",
               "Surname": "JONES"

Client Delivery Remark

Add client delivery remarks by sending Traveler/Address/role with a value of delivery.

Client delivery remarks are not returned in the PNR retrieve.

The following example shows Traveler/Address/role set to Delivery, causing this address information to be recorded as the client delivery address. All of the information below becomes part of the remark.

    "Address": [
      {
        "role": "Delivery",
        "Number": {
          "value": "563"
        },
        "Street": "Northeast Industrial Parkway",
        "City": "Claremont",
        "StateProv": {
          "value": "CA"
        },
        "Country": {
          "value": "US"
        },
        "PostalCode": "91711-3323"
      }
    ],

 

Minimum Secure Flight Information (SSR DOCS)

Not supported for NDC.

AirReservation supports adding the following required minimum secure flight information: 

  • traveler name
  • birthdate
  • gender (supported values are Male, Female, and Unknown)

Send these details in the Add Traveler step of booking. AirReservation adds this data to the SSR DOCS shared with carriers.

If gender is not provided or is invalid, AirReservation creates the PNR and returns the warning INVALID - PASSENGER GENDER MISSING. Until update/change functionality is fully implemented, you must resolve the issue by canceling the PNR and creating a new PNR with the correct details.
Birthdate is mandatory. If not provided, the PNR is created but the minimum SSR DOCS is not created; no error message is returned.

The following example shows the beginning of the Add Traveler payload with the required name, birthdate, and gender details. 

{
  "Traveler": {
    "passengerTypeCode": "ADT",
    "birthDate": "1990-01-15",
    "gender": "Male",
    "PersonNameDetail": {
      "Prefix": "Mr",
      "Given": "JORDAN",
      "Surname": "LOYTEST",
      "Suffix": ""
    }, ...

Child DOB (SSR CHLD)

Not supported for NDC.

For GDS only, AirReservation supports creating a child SSR (SSR CHLD) when a child traveler is on the PNR with date of birth (DOB) information. To ensure the SSR is created, you must include the birthdate when you add the child traveler in Traveler/birthdate. See Booking Workflow for examples.

The workbench commit response returns the Traveler date of birth information when it is sent for a child, as does the PNR retrieve. The specific SSR with the DOB is in the Galileo PNR/BF retrieve.

Remarks Requested in Add Remarks Payload

POST Request

Remarks that are not part of the Add Traveler step are sent in a separate Add Remarks step. You can send Add Remarks either as an optional step in the initial booking workflow, or you can establish a post-commit workbench to add the remark to an existing PNR:

  1. Create workbench.

  2. Send Add Remarks:

    1. For an initial booking send Add Remarks after the Add Traveler step.

    2. For an existing booking send Add Remarks at any point after creating the workbench.

  3. Commit workbench.

The POST request for these remarks varies and is noted individually below.

Primary contact information (SSR CTCE, CTCM, CTCR)

POST

book/primarycontact/reservationworkbench/{workbenchID}/primarycontacts

Base path:

Pre-production https://api.pp.travelport.com/9/air/

Production https://api.travelport.com/9/air/

AirReservation supports the following types of optional SSR remarks for primary contact information:

  • SSR CTCE: E-mail address contact information
  • SSR CTCM: Mobile phone number contact information
  • SSR CTCR: Primary contact information refused

Supported for GDS on all versions of AirReservation.

Supported for NDC in AirReservation 21.11.8 and later as follows:

  • For NDC, CTCM and CTCR are supported during the initial booking workflow only for carriers Singapore (SQ) and American (AA). Adding or deleting to or from an existing PNR is supported only for AA.
  • NDC does not support CTCR.

At many airlines these SSRs are used for passenger contact automation systems to automatically send customer flight information as an email, digital message, or phone voice message. AirReservation does not use IATA SSR contact codes. Instead, after adding a traveler, send a payload with the PrimaryContact object including contact information for mobile number and/or email address. AirReservation sends the necessary information to the carrier for the SSR.

To create a SSR CTCR (primary contact information refused), send PrimaryContact with only the traveler ID and no contact information. AirReservation creates the refused SSR CTCR on the GDS PNR to send to the airline.

This type of remark can be added either during the initial reservation workflow, or to an existing PNR.

SSRs are returned in the PNR retrieve in the same format they were sent. In other words, the PNR lists the SSR as the PrimaryContact info. The actual SSR is created on the airline PNR/BF.

You can send multiple types of contact information in a request; however, only send one traveler ID per request.
To send the information to all suppliers, use the value YY in the shareWithSupplier attribute. Or, specify one or more suppliers with their two-letter airline code.
AirReservation automatically converts the email @ sign sent for an email address to the appropriate Galileo native format for the native PNR/BF.
Send the mobile number either as one number sequence (e.g., 9515550963) or with dashes (e.g,, 951-555-0963), up to a maximum of 50 characters.

The following example shows the AirReservation 20.9.1 PrimaryContact payload to create an SSR CTCM. It sends Telephone with role set to Mobile. 

{
  "PrimaryContact": {
    "shareWithSupplier": [
      "DL",
      "LH",
      "BA"
    ],
    "Telephone": {
      "@type": "Telephone",
      "countryAccessCode": "2",
      "areaCityCode": "907",
      "phoneNumber": "5551244",
      "id": "telephone_2",
      "cityCode": "DEL",
      "role": "Mobile"
    },
    "TravelerIdentifier": {
      "Identifier": {
        "value": "45a25a86-3a09-479e-8c4d-ea8425f844c9"
      }
    }
  }
}

The following example payload creates an SSR CTCR remark in AirReservation. Omitting contact information indicates the passenger refused to provide it. 

{
    "PrimaryContact": {
        "shareWithSupplier":["YY"],
        "shareWith":"Supplier",
        "travelerRef": {travelerID}
    }
}

Disability SSR

POST

book/specialservices/reservationworkbench/{workbenchID}/specialservices/list

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/9/air/

Production https://api.travelport.com/9/air/

Not supported for NDC.

For GDS only, AirReservation supports optional remarks for disability conditions.

This type of remark is sent in a Special Service List payload. It can be added either during the initial reservation workflow, or to an existing PNR.

Specific disability SSRs require varying formats. You can send SSR disability requests for a specific traveler or for all travelers on the PNR, and you can send an SSR for a specific offer or for all segments on the PNR. For detailed examples download the Disability Request Payload Options Guide.

SSRs for disability are returned in the PNR retrieve.

The following SSR codes are supported. Do not send the SSR codes; instead, see the Disability Request guide above for specifics of the payload.

SSR Code Description

BLND

Traveler is blind.

DEAF

Traveler is deaf.

DPNA

Disabled Passenger with intellectual or development disability needing assistance.

WCHC

Wheelchair is needed – traveler is completely immobile.

WCHR

Wheelchair is needed – traveler can ascend/descend stairs.

WCHS

Passenger cannot ascend/descend steps but is able to make own way to/from cabin seat. Requires wheelchair for distance to/from aircraft or mobile lounge and must be carried up/down steps.

WCLB

Wheelchair Lithium ION battery to be transported by a passenger which will require advance notification/preparation. Weight and dimensions may be specified. Wheelchair and battery must be claimed and rechecked at each interline transfer point.

WCMP

Wheelchair manual power to be transported by passenger. Weight and dimensions may be specified.

WCBW

Wet cell battery to be transported by passenger. Will require advance notification and may require preparation/(dis)assembly. Weight and dimensions may be specified. Wheelchair and battery must be claimed and rechecked at each interline transfer point.

WCBD

Wheelchair non-spillable battery to be transported by a passenger which will require advance notification/preparation. Weight and dimensions may be specified. Wheelchair and battery must be claimed and rechecked at each interline transfer point.

The following example shows the payload to create an SSR for BLND. TravelerIdentifier/Identifier/value must be the traveler ID sent in the Add Traveler step.

{
  "SpecialServiceListRequest": {
    "SpecialServiceID": [
      {
        "@type": "SpecialServiceBlind",
        "blindAssistanceRequestedInd": true,
        "id": "specialService_1",
        "Identifier": {
          "authority": "Travelport",
          "value": "A0656EFF-FAF4-456F-B061-0161008D7C4E"
        },
        "TravelerIdentifier": {
          "id": "trav_1",
          "TravelerRef": "trav_1",
          "Identifier": {
            "authority": "Travelport",
            "value": "5250500b-51ab-4f79-82bc-494753114b74"
          }
        }
      }
    ]
  }
}

OSI Comments

POST

book/remarks/reservationworkbench/{workbenchID}/reservationcomments/list

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/9/air/

Production https://api.travelport.com/9/air/

Not supported for NDC.

Other Service Information (OSI) comments are messages sent directly to the supplier to communicate traveler preferences or requirements. Unlike SSRs, OSIs are informational only and do not require the supplier to take action.

This type of remark can be added either during the initial reservation workflow, or to an existing PNR.

You can send multiple comments in one payload by including each comment in its own name and/or value attribute per the example below.

OSI remarks are supported from 1 to 99 characters inclusive. AirReservation returns the error message "OSI REMARK TEXT MUST BE BETWEEN 1 AND 99 CHARACTERS LONG" if the length is outside the required range.
OSI remarks support the special characters . (period), / (forward slash), and - (dash). AirReservation returns the error message "INVALID CHARACTER IN TEXT" if other special characters are sent.
If an OSI remark is requested for NDC content, AirReservation returns the error message “OSI Remark not supported for NDC content".

OSI comments are returned in the PNR retrieve. The response returns an HTTP 204 No Content response message.

The example below sends several OSI comments. 

{
 "ReservationCommentListRequest": {
  "ReservationCommentID": [
   {
    "@type": "ReservationComment",
    "id": "reservationComment_1",
    "Comment": [
     {
      "value": "THANKS FOR BOOKING WITH US"
     },
     {
      "value": "T2"
     },
     {
      "name": "H*",
      "value": "Adding GM with Qual H and Star."
     }
    ]
   }
  ]
 }
}

General Remarks

POST

book/remarks/reservationworkbench/{workbenchID}/reservationcomments

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

You can add any general comment as freeform text during the reservation process. The payload consists of the ReservationComment object per the example below.

Remarks can be added to the PNR to document various parts of the booking or ticketing process. For example, it is common to add a general remark when a ticket is issued at a non-refundable fare and the agent wants to document the fact that the traveler was advised of penalties. They also can be used as a way to satisfy back-office/mid-office rules for policy adherence.

This type of remark can be added either during the initial reservation workflow, or to an existing PNR.

The response returns an HTTP 204 No Content response message.

For GDS only, any general remarks added are returned in the ReservationComment object in the PNR retrieve. 

{
  "ReservationCommentRequest": {
    "id": "reservationComment_1",
    "commentSource": "Agency",
    "shareWith": "Agency",
    "Comment": {
      "value": "INVOLUNTARY REROUTE PER PUBLISHED FARE RULE",
      "name": "General Remarks",
      "language": "EN"
    }
  }
}

Back office remarks

POST book/backoffice/reservationworkbench/{workbenchID}/backoffices

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/9/air/

Production https://api.travelport.com/9/air/

Back office remarks can be sent individually or consolidated into one payload. Each remark type is sent in a separate object in the BackOffice object:

  • Accounting: Accounting remarks, such as optional remarks typically used by an agency's back office system in some way

  • CommissionAmount: Commission as currency amount

  • CommissionPercent: Commission as a percentage

  • DestinationPurpose: DestinationPurpose

  • TourCode: Any tour code. Optional in AirTicketing 20.9.x releases.

This type of remark can be added either during the initial reservation workflow, or to an existing PNR.

The response for all back office remarks returns an HTTP 204 No Content response message. Back office comments are not returned in the PNR retrieve. 

  "BackOffice": {
      "DestinationPurpose": {
        "@type": "DestinationPurpose",
        "destination": "Islands and Countries of the Caribbean",
        "purpose": "Pleasure"
     }
  }
{
  "BackOffice": {
    "id": "backOffice_1",
    "BackOfficeRef": "backOffice_1",
    "TourCode": {
      "type": "Bulk Tour",
      "value": "66196619661966"
    }
  }
}
{
  "BackOffice": {
    "CommissionAmount": {
      "@type": "CommissionAmount",
      "Amount": {
        "value": 123.5
    }
}
{
    "BackOffice": {
        "CommissionPercent": {
            "@type": "CommissionPercent",
            "Percent": "12"
     }
  }
}
  "BackOffice": {
    "Accounting": [
      {
        "@type": "Accounting",
        "NameValuePair": [
          {
            "value": "PTR 11521017475 AMT 0.00",
            "name": "A"
          },
          {
            "value": "FOP 18410925604",
            "name": "A"
          },
          {
            "value": "PTN PCLN",
            "name": "A"
          }
       }
    ]

{
 "BackOffice": {
  "id": "backOffice_1",
  "BackOfficeRef": "backOffice_1",
  "Accounting": [
   {
    "NameValuePair": [
     {
      "value": "ACCOUNTING REMARK UPDATED"
     }
    ]
   }
  ],
  "DestinationPurpose": {
   "@type": "DestinationPurpose",
   "destination": "Islands and Countries of the Caribbean",
   "purpose": "Pleasure"
  },
  "Commission": {
   "@type": "CommissionAmount",
   "Amount": {
    "code": "USD",
    "value": 101.45
   }
  },
  "TourCode": {
   "type": "Bulk Tour",
   "value": "Tour"
  },
  "Restriction": [
   "NON REFUNDABLE AMOUNT"
  ]
 }
}