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 Service Requests Support
• Workflows to Add and Delete Remarks
• Add Traveler Remarks and SSRs
  • Endpoints and Response
  • Traveler documents (SSR DOCO and DOCS)
  • Form of ID ( SSR FOID)
  • Client Delivery Remark
  • Minimum Secure Flight Information (SSR DOCS)
  • DOB (SSR CHLD)
  • Traveler Name Remarks
• Primary Contact Remarks
  • Endpoints and Response
  • Primary Contact (email, phone, or contact refused) (SSR CTCE, CTCM, CTCR)
• Special Service List SSRs
  • Endpoints and Response
  • Special Service Request - Disability
  • Special Service Request - Meals
• Document Overrides
  • Endpoints and Response
  • Document Override Remarks (tour code, commission, endorsement)
  • Document Overrides in GDS Exchanges (change fee collection, EMD endorsement, commission)
• Accounting Remarks
  • Endpoints and Response
  • Accounting, Historical, and DOCI Remarks
•  Reservation Comments Remarks
  • Endpoints and Response
  • OSI Remarks
  • Notepad Remarks
    • Spanish Residency/Large Family Fares
  • Vendor Remarks
  • Itinerary Remarks - Associated & Unassociated
• Add Offer SSRs
  • Endpoint
  • India GST SSR

Basic Concepts

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

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.

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.

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)

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

All traveler information sent is returned in the reservation retrieve.

Form of ID (SSR FOID)

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

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)

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.

Child DOB (SSR CHLD)

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.

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

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.

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

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.

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.

Special Service Request - Meals (SSR meal code)

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.

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

Document Overrides Payload Remarks

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)

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

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 above with the following additions.

Change fee collection method

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

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

book/reservationworkbench/{workbenchID}/accountings/{id}/namevaluepairs?NameValuePairIds={NameValuePair_value} 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

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.

Accounting DOCI remarks

Accounting historical remarks

Reservation Comments Payload Remarks

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

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.

Notepad Remarks

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.

Spanish Residency and Large Family Discount Fares

Spanish residency and large family discount fares are available to residents of Spain for NDC on carrier IB only, When booking these fares, use notepad remarks as follows:

Send one remark per traveler. Either an HR Resident or HR Family remark is required. This is used to validate traveler residency and documentation.

For Spanish residency discount:

• Send Comment/name with the value HR

• Send Comment/value with the exact string format RESIDENT {Type of ID}/{Number of ID}/{Municipal Code}//{Traveler Ref}]//

• RESIDENT is expected by the carrier.

• Supported values for type of ID:

  • DN: DNI/National Document

  • GR: Senator/Representative

  • TR: NIE/Foreign resident card

  • MR: Minor of 14 years old with no DNI

• [Number of ID] is the ID number. When the type of ID is MR, send date of birth in the format DDMMYYYY

• [Municipal Code]

• [Traveler Ref]: Do not send a JSON API traveler identifier. Instead send P1 for the first traveler, P2 for the second traveler, etc.

• // notes the end of string

• Example: RESIDENT DN/12345678Z/070027/P1//

 

For large family discount, send Comment/name with the value HF and Comment/value with FAMILY at the beginning of the string.

• Send Comment/name with the value HF

• Send Comment/value with the exact string format FAMILY {Family Category}{Type of ID}/{Number of ID}/{Municipal Code}/{Certificate Number}//{Traveler Ref}//

• FAMILY is expected by the carrier.

• {Family Category} supported values:

  • F1 = for families with 3 children

  • F2 = for families with 4 or more children

• {Type of ID}

  • DN: DNI/National Document

  • TR: NIE/Foreign resident card

  • MR: Minor of 14 years old with no DNI

• [Number of ID] is the ID number. When the type of ID is MR, send date of birth in the format DDMMYYYY

• {Municipal Code}

• {Certificate Number}

• [Traveler Ref]: Do need send a JSON API traveler identifier. Instead send P1 for the first traveler, P2 for the second traveler, etc.

• // notes the end of the string

• Example: FAMILY F1DN/12345678Z/410917/9999999999/P1//

 

Send HR SARA only if a traveler has a second last name. If a SARA remark exists then this name will be sent to the carrier and used to issue the ticket. The traveler name in the workbench is used to create the name field on the booking.

• Send Comment/name with the value HR

• Send Comment/value with the exact string format SARA {1stlastname}/{2ndlastname}/{1stname middlename}/{Traveler Ref}//

• SARA is expected by the carrier.

• {1stlastname}

• {2ndlastname}

• {1stname middlename}

• A space is required between the first name and middle name.

• [Traveler Ref]: Do need send a JSON API traveler identifier. Instead send P1 for the first traveler, P2 for the second traveler, etc.

• // notes the end of the string

• Example: SARA: Ortega Smith/Molina/Francisco Javier/P1//

 

Vendor Remarks

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.

Itinerary Remarks - Associated and Unassociated

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

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

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.