Search Workflows

The Search APIs offer In the JSON Search APIs, an offer is a product available at a specific price under a set of terms and conditions. An offer includes the flight or connecting flights for one leg of the itinerary, plus a service level that includes the cabin class and any fare codes that may apply. At booking, the selected offer from the Search response - including the flight/s, service level, price, terms and conditions, and brand if applicable - is converted into a single Offer object that is subsequently returned for that booking. a number of workflows, determined by whether the initial Search response returns offers for all legs of the itinerary The entire trip on a booking, including all flights on all legs. Also called a journey. (a journey-based A Search that returns offers for all legs on the itinerary. A journey-based Search request is a standalone search. No additional search requests are required. See leg-based below. search) or only the first leg The flight or connecting flights between one origin and destination pair. For example, on a round-trip flight, LAX > MSP could be the first leg (aka outbound leg) and MSP > DEN > LAX could be the second leg (aka inbound leg). The JSON APIs use the term product (see below) to represent one leg of the itinerary. (a leg-based A Search that returns offers for only the first leg of the itinerary. Must be followed by a Next Leg Search request that selects an offer for the first leg and returns offers to combine with that leg. A multi-city itinerary requires another Next Leg Search for the third leg. See the Air Shopping Guide for details. See journey-based above. search). A leg-based round-trip An itinerary in which travel goes to a single destination and returns to the origin. E.g., LHR > CDG and CDG > LHR. or multi-city An itinerary that includes multiple destinations; e.g., LHR > CDG > AMS > BCN. search must be followed by a Next Leg Search to return offers on the subsequent leg/s of the itinerary.

Send SearchRepresentation with the value Leg for a leg-based search or Journey for a journey-based search. If CustomResponseModifiersAir is not sent, the default is a journey-based response.This setting does not apply to one-way An itinerary with a single destination; e.g., LHR > CDG. searches and is ignored if sent for one-way.

If your workflow subsequently references a journey-based search result, the Search request must send offersPerPage set to any positive number. This setting invokes caching to allow subsequent requests to refer to these search results. (A journey-based search returns all legs of the itinerary, while a leg-based search returns one leg at a time and is cached by default.) If a journey-based Search request does not send offersPerPage, any reference payload In the JSON APIs, an API call that sends identifers referring to a previous response for the itinerary to be shopped, priced, added, etc. instead of full itinerary details. requests for Flight Specific Search, AirPrice, and Add Offer will fail.

In addition, if sent with a non-zero number, offersPerPage determines the number of offers returned in the response. If not sent, or sent with 0, Search returns all offers. Note that if offersPerPage is sent with 1, Search returns one offer for only one leg. This defect will be addressed in an upcoming release to ensure that the single offer returned includes all legs in the Search criteria.

Search and Next Leg Search can return up to 4 upsells A fare presented along with the base fare as a higher level of service, usually a branded fare. Returned if filed by the carrier and requested with maxNumberOfUpsellsToReturn in the Search request. per any offer, as set in the request payload with the optional maxNumberOfUpsellsToReturn object. Flight Specific Search is an optional request to return up to 99 upsells, or as many as the carrier An airline. has filed, for any leg or offer returned in a previous Search or Next Leg Search.

Each box in the diagram represents one API call in the workflow.