Remarks & Service Requests Guide & API Reference

The JSON APIs support several types of remarks and service requests as part of the booking workflow:

  • Some remarks, such as travel document details, are sent in the Add Traveler payload in the initial booking workflow. For an existing reservation, these remarks can be added, modified, or deleted using the Traveler Updatable Items and Traveler Update requests detailed in the Traveler Modify Guide.

  • Other remarks are sent in a separate payload. These can be added or deleted with a single direct request in either the initial booking workflow or for an existing reservation.

This combined guide and API reference provides endpoints and examples for adding all remarks, and for deleting remarks sent in payloads other than the Add Traveler payload. To modify or delete Add Traveler remarks, see the Traveler Modify Guide.

Related Content: JSON APIs Guide, Booking Guide, Traveler Modify Guide

In this topic:

This topic groups remarks by the request payload in which they are sent, as follows:

Basic Concepts

Remarks and optional services cover many kinds of notes and special requests that can be added to a reservation.

Because terminology varies, especially for NDC, this guide uses the generic terms remarks and service requests. Because some customers may be more familiar with the SSR codes and other terms used, however, those details are included below when relevant even though those codes are not sent or returned in the JSON API requests/responses.

A service request, also known in the airline industry as an SSR, for special service request, 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. These service requests include information such as meal preference or special assistance required for the traveler. Because the carrier must take action, 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 predefined by IATA; however, not all carriers support the use of all SSR codes. The JSON APIs do not send or return the IATA SSR codes; instead, they send specific information during booking and/or ticketing to the carrier, which transforms the necessary information into the appropriate SSR as needed.

You can also add various remarks to the reservation. Sometimes called OSI requests, for other service information, these are informational messages sent directly to the carrier to communicate traveler preferences or requirements. Unlike SSRs, OSIs are typically used to notify a carrier of special circumstances and do not require the carrier to take action.

Remarks and Service Requests Support

The following table outlines the remarks and service requests supported in the JSON APIs, and when in the workflow those requests can be added or deleted.

To modify or delete the remarks added via the Add Traveler Payload, see the Traveler Modify Guide.

To delete remarks not sent in the Add Traveler payload, use the DEL requests in this topic. AirReservation does not support PUT commands to directly modify these remarks. Instead, delete the remark and add a new remark; see Workflows to Add and Delete Remarks next.

Not all NDC carriers support all types of remarks that can be sent in the Accounting and Reservation Comments payloads. If a specific NDC carrier does not support a remark, AirReservation creates and stores the remark in the Travelport booking record only and does not send that remark to the carrier.

Remark/service request sent in payload

GDS

NDC

Add in initial booking workflow

Delete in initial booking workflow

Add to an existing reservation

Delete from existing reservation

Returned in reservation retrieve

Add Traveler payload - only during initial booking (modify, delete, and add per the Traveler Modify Guide)

Traveler documents (SSR DOCO and DOCS)

Yes

Yes

Yes

Yes

Yes

Yes

Yes for GDS

Not returned for NDC

Form of ID ( SSR FOID)

Yes

No

Yes

Yes

Yes

Yes

Yes

Client delivery remark

Yes

Yes

Yes

No

Yes

No

No

Minimum secure flight information (SSR DOCS)

Yes

No

Yes

No

Yes

No

Yes

DOB (SSR CHLD)

Yes

No

Yes

No

No

No

Yes

Primary Contacts payload (delete these and all following remarks in this table using the DEL requests in this topic for each payload)

Primary contact remarks (SSR CTCE, CTCM, CTCR)

Yes

Yes, specific carriers only

Yes

No

Yes

Yes

Yes

Special Service List payload

Special service request - Disability

Yes

Yes

Yes

No

Yes

No

Yes

Special service request - Meals

Yes

Yes, specific carriers only

Yes

Yes

Yes

Yes

Yes

Reservation Comments payload

OSI remarks

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Notepad remarks

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Vendor remarks

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Itinerary remarks - associated & unassociated

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Document Overrides payload

Document override remarks

Yes

No

Yes

No

Yes

No

Returned if detailViewInd query parameter is set to true

Accounting payload

Accounting, historical, DOCI remarks

Yes

Yes

Yes

Yes

Yes

Yes

Returned if detailViewInd query parameter is set to true

Add Offer payload

India GST SSR

Yes

Yes

Yes

No

No

No

Yes for GDS

Not returned for NDC

Workflows to Add and Delete Remarks

The following tables outline the process for adding remarks in the initial booking workflow, and for adding and deleting remarks from an existing reservation.

Remarks sent in the Add Traveler payload can be added, modified, or deleted using the Traveler Updatable Items and Traveler Update requests detailed in the Traveler Modify Guide.

During any workbench session, if you retrieve the workbench to view updates, the retrieved workbench does not yet show the added or deleted remarks. The change appears only after the workbench is committed. After you commit the workbench you can retrieve the reservation to see the changes.

Adding/deleting remarks in the initial booking workflow
Step #

Workflow Step

Description and Notes

API Reference

1

Create workbench

Create a new workbench.

Returns a system-generated identifier for the workbench that must be sent in subsequent requests for that workbench.

Create New Workbench API Reference

2 or 3

Add offer

Add the air offer.

Add Offer API Reference

2 or 3

Add traveler

Add each traveler. Include in the Add Traveler payload any remarks supported in that payload as desired.

(After the booking is created, remarks sent in the Add Traveler payload are added, modified, or deleted using the Traveler Updatable Items and Traveler Update requests detailed in the Traveler Modify Guide.)

See Add Traveler Remarks and SSRs below

Also see the Add Traveler API Reference

 

4

Add other remarks as needed

Per the sections below, send the appropriate POST request to add any remarks not sent in the Add Traveler payload.

For special service requests, only one kind of service request is supported in the same payload. For example, you can send multiple special assistance requests (disability SSRs) but not a request for a wheelchair and a special meal request (disability and meal SSRs).

See section in this topic for each remark

5

Retrieve workbench (optional - only if deleting a remark)

If needed, retrieve the workbench to get the identifier/s for the item/s to modify.

Retrieve Workbench API Reference

6

Delete a remark if needed (optional - only if deleting a remark)

Not all remarks are supported for deletion. See the Support section above.

Send the DEL request from the appropriate section below to delete a remark.

AirReservation does not support PUT commands to directly modify these remarks. Instead, delete the remark and add the new remark.

See section in this topic for each remark

5

Commit workbench

Final step in the workflow.

The response returns the reservation in the same format as a reservation retrieve response, including updates for most remarks.

Commit Workbench API Reference

 

Adding/deleting remarks for existing reservation
Step #

Workflow Step

Description and Notes

API Reference

1

Create workbench

Create a post-commit workbench for an existing booking.

Returns a system-generated identifier for the workbench that must be sent in subsequent requests for that workbench.

Create Post-Commit Workbench API Reference

as needed

Add remark as needed (optional)

Send the appropriate POST request to add any remark not sent in the Add Traveler payload, per the sections below. (To modify/delete/add remarks from the Add Traveler payload, see the Traveler Modify Guide.)

See section in this topic for each remark

as needed

Send DEL request to delete remark if needed (optional)

Not all remarks are supported for deletion. See the Support section above.

Send the DEL request from the appropriate section below to delete a remark.

AirReservation does not support PUT commands to directly modify these remarks. Instead, delete the remark and add the new remark.

See section in this topic for each remark

as needed

Additional request for same type of item (optional)

On an existing reservation, to send an additional request for the same type of item (such as deleting an SSR and adding a new SSR, or deleting two SSRs):

  • For GDS you can make multiple adds or deletes for the same type of item in the same workbench session, but you must retrieve the workbench between each add or delete to synchronize the reservation with the host session.
  • For NDC you can add or delete only one of the same type of item per commit. Commit the workbench and repeat this workflow to add or delete another of the same type of item.

Workbench Retrieve for GDS

For NDC, go to next step for Workbench Commit, then repeat workflow.

final step

Commit workbench

Final step in the workflow.

The response returns the reservation in the same format as a reservation retrieve response, including updates for most remarks.

Commit Workbench API Reference

 

Add Traveler Remarks and SSRs

Endpoints and Response

Remarks in this section are sent in the Add Traveler payload during the following initial booking workflow.

After the reservation is created, these remarks can be added, modified, or deleted using the Traveler Updatable Items and Traveler Update requests detailed in the Traveler Modify Guide.

Send the following POST request for the Add Traveler step. See the Add Traveler API Reference for additional details and examples.

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/11/air/

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

See the following sections for the payload for each traveler remark.

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

Travel Documents (SSR DOCO and DOCS)

See Endpoints above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Some carriers require specific traveler information on certain routes, such as valid travel documents for international routes. Send passport, visa, etc. details in the TravelDocument object. If multiple travel documents are needed, include additional instances of TravelDocument.

AirReservation supports the following types of travel documents and converts them to the appropriate remark or SSR code as follows. No special formatting is required, and the information is automatically populated for the reservation.

Type of travel document

Value to send in TravelDocument/docType

SSR Code (informational only - not sent or returned in AirReservation)

Passport

Passport

SSR DOCS P

Redress

Redress

SSR DOCO R

Known Traveler

KnownTraveler

SSR DOCO K

Visa

Visa

SSR DOCO V

When adding visa information, both issueDate and expireDate are required. Date formats are the Travelport JSON API standard YYYY-MM-DD.

All traveler information sent is returned in the reservation retrieve.

Form of ID (SSR FOID)

See Endpoints above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

GDS only; not supported for NDC.

For carriers who require it, the JSON APIs convert information about the form of ID used to the SSR Form of ID (FOID). You can send any of these types of ID to be converted to the SSR FOID:

  • passport (send TravelDocument object with docType Passport)
  • driver's license (send TravelDocument object with docType DriversLicense)
  • frequent flyer (send CustomerLoyalty object)

All traveler information sent is returned in the commit step and in the reservation retrieve.

Client Delivery Remark

See Endpoints above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

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

Client delivery remarks are not returned in the reservation retrieve.

Minimum Secure Flight Information (SSR DOCS)

See Endpoint above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.
GDS only. Not supported for NDC.

Certain carriers on certain routes are required by the US Transportation Security Administration (TSA) to send the following required minimum secure flight information for every traveler as part of the Add Traveler payload; AirReservation converts this data to the format required by carriers: 

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

All traveler information sent is returned in the reservation retrieve.

If a gender is not provided or is invalid, AirReservation creates the reservation and returns the warning INVALID - PASSENGER GENDER MISSING.

Birthdate is mandatory. If not provided, AirReservation creates the reservation and returns the warning INVALID - DATE OF BIRTH MISSING. The minimum SSR DOCS is not created.

Neither situation returns an error. Until update/change functionality is fully implemented, you must resolve the issue by canceling the reservation and creating a new reservation with the correct details.

Child DOB (SSR CHLD)

See Endpoints above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.
GDS only. Not supported for NDC.

For GDS only, AirReservation creates a child SSR (SSR CHLD) when a child traveler (any of the Travelport child traveler PTC codes) is on the reservation with date of birth (DOB) information. To ensure the carrier receives the required information, you must include the birthdate in Traveler/birthDate when you add the child traveler in the Add Traveler payload.

For both GDS and NDC, the child date of birth can be made mandatory or regulated with PCC configuration. If configured as mandatory for that PCC, if the child date of birth is not provided in the Add Traveler request, AirReservation returns the error Date of Birth for child is missing. Contact your Travelport representative for any configuration questions.

The workbench commit response returns the traveler date of birth when it is sent for a child, as does the reservation retrieve. Traveler birthdate information cannot be added or modified after that traveler is added.

Traveler Name Remarks

AirReservation 23.11.35 and later.

The optional Comments object in the Add Traveler request payload supports sending custom, freeform traveler name remarks, such as a unique identifier for that traveler. Send Comments/Comment with the following:

  • value: Free text traveler name remark. Up to 33 characters, only spaces and hyphens allowed for special characters.

  • id: Local identifier to use for this remark.

Returned in the reservation retrieve response in Traveler/Comments.

Primary Contact Payload Remarks

Endpoints and Response

Remarks in this section use the following POST request to create the remark.

POST

book/primarycontact/reservationworkbench/{workbenchID}/primarycontacts

Base path:

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

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

Use the following DEL request to delete any primary contact remark.

DEL

book/primarycontact/reservationworkbench/{workbenchID}/primarycontacts/{PrimaryContactID}/

For {PrimaryContactID} above send the system-generated identifier for the contact to delete.

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/11/air/

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

AirReservation does not support PUT commands for directly modifying these remarks. Instead you must delete a remark and then add the new remark. See Workflows to Add and Delete Remarks above.

See the following sections for the payload for each primary contact remark.

The Primary Contact request returns the following response. Primary contact details are returned in the reservation retrieve.

Primary Contact Information (email, phone, or contact refused) (SSR CTCE, CTCM, CTCR)

AirReservation supports the following types of optional remarks for primary contact information, also known by the following SSR codes:

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

At many airlines this information is used for passenger contact automation systems to automatically send customer flight information as an email, digital message, or voice message.

AirReservation does not use IATA SSR contact codes. Instead, after adding a traveler, send a PrimaryContacts payload with 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 without any contact information. AirReservation creates the SSR CTCR on the GDS reservation to send to the airline.

Notes on contact information

You can send multiple types of contact information in a single request, but you can send only one traveler ID per request.

To send the information to all suppliers, send shareWithSupplier with value YY. 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 reservation/BF.

Send the mobile number either as a single number sequence (e.g., 9515550963) or with dashes (e.g., 951-555-0963), up to a maximum of 50 characters.

Supported for GDS. Supported for NDC as follows:

    • NDC does not require primary contact information on a booking. Instead, contact information can be added for each passenger.
    • You can delete contact information prior to committing the initial booking workbench.
    • CTCM and CTCE are supported during the initial booking workflow only for carriers SQ, AA, AF/KL, LHG , and BA.
    • Adding CTCM and CTCE to or deleting from an existing reservation is supported only for AA, AF/KL, LHG, and BA.
    • CTCR is supported only for QF, AF/KL, and LHG.

Special Service List SSRs

Endpoints and Response

All remarks in this section use the following POST request to create the remark.

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/11/air/

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

Use the following DEL request to delete any Meal SSR. Disability SSRs are not supported for deletion at this time.

DEL

book/specialservices/reservationworkbench/{workbenchID}/specialservices/{SpecialServiceID}

For {SpecialServiceID} send the system-generated identifier for the remark to delete.

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/11/air/

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

AirReservation does not support PUT commands for directly modifying these remarks. Instead you must delete a remark and then add the new remark. See Workflows to Add and Delete Remarks above.

See the following sections for the payload for each special service list remark.

The response returns an HTTP 200 No Content message for GDS and HTTP 204 No Content message for NDC.

Special Service Request - Disability SSR

See Endpoints above for endpoints and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Optional remarks for disability special service requests can be added either during the initial reservation workflow, or to an existing reservation.

Disability service details are returned in the reservation retrieve. They cannot be deleted, but they can be added to an existing reservation.

Only one kind of special service request is supported in the same payload. For example, you can send multiple special assistance requests in the following payload but not a request for a wheelchair and a special meal request.

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

The following SSR codes are supported. Do not send the SSR codes; instead, refer to the Disability Request Payload Options guide for the specific payload for each type of disability request by SSR code.

SSR Code (informational only; do not send ) 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 request payload below supports either the object name SpecialServiceID or SpecialService.

Special Service Request - Meals (SSR meal code)

See Endpoints above for endpoint and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

You can send special meal requests for passengers with dietary constraints when a meal service is offered by the airline on a flight. At this time special meal requests are supported for GDS, and for NDC only on carriers American Airlines (AA), Qantas Airways (QF), and United Airlines (UA). Additional NDC airlines and pre-paid ancillary meal requests will be available later.

Special meal requests are returned in the reservation retrieve in the SpecialService object. Special meal requests can be added during booking or to an existing reservation, and can be deleted.

The JSON APIs support the 21 most commonly requested free meal types as an enumeration per the mapping below. The carrier must also support the requested meal type for the meal to be provided to the traveler.

Free meals are usually only offered in premium cabins, or on flights that are more than six hours. However, each airline may support free meal type requests using different criteria.

As currently supported by airlines, all free meal requests are on a request-only basis, and neither the airline nor Travelport guarantee the specific meal offering will be available, supported, and provided to the traveler on their selected flight. Travelers should always advise the airline at check-in, boarding, and/or with cabin staff about special meal requests.

IATA Code (informational only; do not send) Enumeration Values Mapping (send in SpecialMealTypeEnum per example below)

BBML

Baby

CHML

Child

DBML

Diabetic

FPML

FruitPlatter

HNML

Hindu

VJML

Jain

KSML

Kosher

LCML

LowCalorie

LFML

LowFat

LSML

LowSalt

MOML

Muslim

NLML

NonLactos

NOML

None

SFML

Seafood

VGML

Vegan

AVML

VegetarianHindu

VLML

VegetarianLactoOvo

VOML

VegetarianOriental

RVML

VegetarianRaw

The request payload below supports either object name SpecialServiceID or SpecialService.
Only one kind of special service request is supported in the same payload. For example, you can send multiple special meal requests in the following payload, but not a special meal request and a request for a wheelchair.

Document Overrides Payload Remarks

GDS only; not supported for NDC.

Endpoint

All remarks in this section use the following POST request to create the remark. See Workflows to Add and Delete Remarks above.

POST

book/documentoverride/Reservation/{workbenchID}/documentoverrides

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/11/air/

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

AirReservation does not support DEL or PUT commands for deleting or modifying document override remarks.

See the following sections for the payload for each document override remark.

All document override requests return the response in the following format.

Document Override Remarks (tour code, commission, endorsement)

GDS only; not supported for NDC.

For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Use document overrides to send remarks such as tour code, commission, or endorsements/restrictions.

Document override remarks are returned in the reservation retrieve only when the detailViewInd query parameter is set to true. Document override remarks can be added to a reservation but cannot be deleted.

Traveler-specific commissions

For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

To send a commission to be applied only to the fare of one or more specific travelers, send traveler details in TravelerIdentifierRef along with the commission to be applied. Commission can be sent as either an amount or percentage.

Document Override Remarks in GDS Exchanges (change fee collection, EMD endorsement, commission)

Several specific document override remarks can be used when exchanging a GDS ticket with the Exchange Ticketing API. Use the same endpoint and payload as for Document Overrides with the following additions.

Change fee collection method

For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

You can use document override remarks to override the change fee collection method from what is returned in the Exchange Search response. If you override from TAX to EMD and the change fee includes a VAT tax, include in the payload the taxIncludedInBaseAmountInd indicator to note how the VAT tax should be collected:

  • True: VAT tax should be included in the change fee amount. The VAT tax will be added to the change fee amount in the SVC segment and an EMD issued for one amount.

  • False: VAT tax should be separated from the change fee amount. The VAT tax will not be added to the change fee amount in the SVC segment and an EMD issued with the change fee amount and a separate tax amount.

You can also specify that a tax should be used to collect the change fee. ChangeFeeCollectionMethod indicates that the change fee collection method returned in the Exchange Search response is being overridden. Specify the two-character tax code to be used as the collection method in code (e.g., OA, DU, CP, XP).

EMD endorsements

The Restrictions/DocumentType object supports endorsements for EMDs as follows. The text of the EMD endorsement itself is sent in Restrictions/Restriction. Supported values for DocumentType are EMD and Ticket:

  • EMD: Up to 145 characters and 1 endorsement line allowed.

  • Ticket: Up to 29 characters and 3 endorsement lines allowed.

Commissions

The Commissions/ApplyTo object allows you to apply an instance of Commissions/Commission to either the change fee (send with a value of Fee) or the base fare (send with a value of Base). To apply a commission to both the change fee and the base fare, send one instance of Commission for each. ApplyTo is supported only in document overrides sent as part of Exchange Ticketing.

In previous versions, any commission sent applies only to the base fare.

Ticket Designator

The TicketDesignator object in the Document Overrides request allows ARC and BSP Canada API customers to add a ticket designator or modify an existing ticket designator during the exchange flow. The ticket designator applies to all travelers on the reservation.

Accounting Remarks

The AirReservation 23.11.33 release made several updates to the remarks in this section. Examples of both the previous and updated payloads and reservation retrieve responses are provided. By default, AirReservation uses the updated payloads and responses. However, AirReservation can use the previous payloads and responses if set in your configuration settings with Travelport; contact your Travelport representative for assistance.
Not all NDC carriers support all types of remarks that can be sent in the Accounting and Reservation Comments payloads. If a specific NDC carrier does not support a remark, AirReservation creates and stores the remark in the Travelport booking record only and does not send that remark to the carrier.

Endpoints and Response

All remarks in this section use the following POST request to create the remark.

POST

book/accounting/reservationworkbench/{workbenchID}/accountings

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/11/air/

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

Use the following DEL request to delete an accounting remark.

DEL

reservationworkbench/{workbenchID}/accountings/{id}/namevaluepairs

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/11/air/

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

AirReservation does not support PUT commands for directly modifying these remarks. Instead you must delete a remark and then add the new remark. See Workflows to Add and Delete Remarks above.

See the following sections for the payload for each accounting remark.

AirReservation returns an identifier in the response for all remarks added with the Accounting payload. The following sections provide examples of the remark as returned in the reservation retrieve response.

Accounting, Historical, and DOCI Remarks

For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Optional accounting remarks can be added to the reservation and are typically used in some way by an agency's back-office system. The remarks can include ticket numbers, customer or account numbers, fares offered to the customer but refused, and canned remarks that document fare rules. Accounting remarks are added to the booking as historical notepad remarks.

To send an accounting free-text remark, or DOCI remark, send an accounting remark with Accounting/dataType value of DOCI and NameValuePair/name value of FT, per the examples below.

Accounting remarks are returned in the reservation retrieve only when the detailViewInd query parameter is set to true. They can be added to an existing reservation and deleted.

The following examples show the payload requests and the remark excerpt from the reservation retrieve response. By default AirReservation now uses the payload and response updated with the 23.11.33 release. However, your configuration settings with Travelport can be updated to support the payload and response returned in 23.11.32 and earlier; contact your Travelport representative for assistance.
Accounting DOCI remarks
Accounting historical remarks

Reservation Comments Payload Remarks

The AirReservation 23.11.29 and .33 releases made several updates to the remarks in this section. Examples of both the previous and updated payloads and reservation retrieve responses are provided. By default, AirReservation uses the updated payloads and responses. However, AirReservation can use the previous payloads and responses if set in your configuration settings with Travelport; contact your Travelport representative for assistance.
Not all NDC carriers support all types of remarks that can be sent in the Accounting and Reservation Comments payloads. If a specific NDC carrier does not support a remark, AirReservation creates and stores the remark in the Travelport booking record only and does not send that remark to the carrier.

Endpoints and Response

All remarks in this section use the following POST request to create the remark.

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/11/air/

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

Use the following DEL request to delete any remark sent in the Reservation Comments payload.

DEL

reservationworkbench/{workbenchID}/reservationcomments/{id}/comments

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/11/air/

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

AirReservation does not support PUT commands for directly modifying these remarks. Instead you must delete a remark and then add the new remark. See Workflow to Add and Delete Remarks above.

See the following sections for the payload for each reservation comment remark.

AirReservation returns the following response for all remarks added with the Reservation Comments payload. The following sections provide examples of the remark as returned in the reservation retrieve response.

OSI Remarks

See Endpoints above for endpoints and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

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

Send OSI remarks per the example below. Send multiple remarks by including each remark in its own name and/or value key value pair.

To ensure the remark is added as an OSI remark, send the following required objects in ReservationCommentID per the examples below:

  • commentSource with the value Agency

  • shareWith with the value Supplier

  • shareWithSupplier is optional; when sent the value is the carrier code of the specific carrier to share with

OSI remarks are returned in the reservation retrieve, where they are identified with a value of Agency in ReservationComment/commentSource.

From 1 to 99 characters inclusive are supported for OSI remarks. 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.

The following examples show the payload requests and the remark excerpt from the reservation retrieve response. By default AirReservation now uses the payload and response updated with the 23.11.33 release. However, your configuration settings with Travelport can be updated to support the payload and response returned in 23.11.32 and earlier; contact your Travelport representative for assistance.

Notepad Remarks

See Endpoints above for endpoints and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Optional notepad remarks can be added to the reservation. To ensure the remark is added as a notepad remark, send the following required objects in ReservationCommentID per the examples below:

  • commentSource with the value Agency

  • shareWith with the value Agency

  • shareWithSupplier is optional; when sent the value is the carrier code of the specific carrier to share with

Notepad remarks are returned in the reservation retrieve by default, where they are identified with a value of Agency in ReservationComment/commentSource.

The following examples show the payload requests and the remark excerpt from the reservation retrieve response. By default AirReservation now uses the payload and response updated with the 23.11.33 release. However, your configuration settings with Travelport can be updated to support the payload and response returned in 23.11.32 and earlier; contact your Travelport representative for assistance.
The JSON APIs do not support the D* (asterisk) value that can be entered in Smartpoint. If Comment/name is sent with a value of D*, the request fails and returns the error message G PRIMARY QUALIFIER MUST BE C OR H OR F IF SECONDARY IS * - General Remarks".

Vendor Remarks

See Endpoints above for endpoints and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Vendor remarks are usually comments made by the airline to send to an agent. These vendor input remarks are not sent in the JSON APIs but rather are typically generated automatically once the booking or request is completed. These usually include the airline's own record locator, replies to special requests, and advice on ticketing time limits.

It is also possible for an agent to send vendor remarks to an airline, called vendor output remarks. When creating a vendor output remark, send the following required values in ReservationCommentID per the examples below:

  • commentSource with the value Supplier

  • shareWith with the value Agency

  • shareWithSupplier is optional; when sent the value is the carrier code of the specific carrier to share with

Vendor remarks for GDS are returned in the reservation retrieve, where they are identified with a value of Supplier in ReservationComment/commentSource. Vendor remarks for NDC are not returned in the reservation retrieve.

The following examples show the payload requests and the remark excerpt from the reservation retrieve response. By default AirReservation now uses the payload and response updated with the 23.11.33 release. However, your configuration settings with Travelport can be updated to support the payload and response returned in 23.11.32 and earlier; contact your Travelport representative for assistance.

Itinerary Remarks - Associated and Unassociated

See Endpoints above for endpoints and response details.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

Associated and unassociated remarks are optional, multi-item freeform strings of text. Associated remarks can be added for an offer, product, or a segment. Unassociated remarks apply to the itinerary and are not associated with a segment.

Per the following examples, use AppliesTo with these @type values:

  • AppliesToOffer for remarks associated with the offer (the entire itinerary)

  • AppliesToOfferProduct for remarks associated with the product (one leg of the itinerary)

  • AppliesToOfferProductSegment for remarks associated with the segment (one flight on the itinerary)

To ensure the remark is added as an itinerary remark, per the examples below, send the following required objects in ReservationCommentID:

  • commentSource with the value Agency

  • shareWith with the value Traveler

  • shareWithSupplier is optional; when sent the value is the carrier code of the specific carrier to share with

The following examples show the complete payload requests and an excerpt of the remark as returned in the reservation retrieve response, for both the previous and updated releases as applicable. By default AirReservation now uses the newer payload and response. However, your configuration settings with Travelport can be updated to support the previous payload and response; contact your Travelport representative for assistance.
The following examples show the payload requests and the remark excerpt from the reservation retrieve response. By default AirReservation now uses the payload and response updated with the 23.11.33 release. However, your configuration settings with Travelport can be updated to support the payload and response returned in 23.11.32 and earlier; contact your Travelport representative for assistance.

The following example requests are from AirReservation 23.11.29. Previous versions did not support sending itinerary remarks but returned them if entered outside the JSON APIs.

The following excerpts shows the itinerary remarks as returned in the Reservation Retrieve response for both offer and segment-level remarks.

The following excerpts show the request and response for unassociated itinerary remarks, which could be sent starting with AirReservation 23.11.29.

Add Offer Payload

Endpoint

All remarks in this section are sent in the Add Offer request. Use the endpoint for either the Add Offer reference payload or Add Offer full payload.

Modifying and deleting remarks sent in the Add Offer payload is not supported.

India GST SSR

To accommodate travel within and from India, AirReservation supports sending GST details as part of the Add Offer payload, which are converted to GST SSRs as applicable. Send GST details as part of the Add Offer request in OrganizationInformation/GSTRegistrationNumber.

GST is a Goods and Services Tax (GST) implemented by the government of India. GST merges several individual taxes into a single tax and is a comprehensive indirect tax on the manufacture, sale, and consumption of goods and services throughout India. GST is applicable to all itineraries for travel wholly within India and flights originating in India to international destinations. The GST is not applicable on international flights to India or Indian domestic connections from such flights. Per Indian law, it is mandatory for the validating carrier to collect the GST data for all applicable travel paid for by a business with a registered GST Number.

IATA created the following four industry standard SSRs to send GST data to the validating carrier where required:

  • GSTN - Goods and Services Tax Number

  • GSTA - Goods and Services Tax Business Address

  • GSTP - Goods and Services Tax Business Phone Number(s)

  • GSTE - Goods and Services Tax Business Email

AirReservation does not validate whether the itinerary originates in India.

It is assumed that customers know the restrictions/limitations for the SSR format including usage of any special characters. If any required details for any of the four GST SSRs are missing, none of the SSRs are added.

GST data is applied to all travelers and all carriers in that reservation. Travelport recommends booking only the applicable traveler and carrier if GST is not relevant to other passengers on a reservation.

GST SSRs cannot be modified on or added to an existing reservation.

For GDS, the OrganizationInformation object with the India GST details is returned in the commit step and in the reservation retrieve in an instance of TermsAndConditionsFullAir.

For NDC, the reservation retrieve does not return OrganizationInformation. Note that the example below could not be used for NDC, which supports OrganizationInformation/GSTRegistrationNumber only in the reference payload, not the full payload Add Offer request shown below, which is supported only for GDS.