Search Workflows

The Search APIs offer a number of workflows, determined by whether the initial Search response returns offers for all legs of the itinerary (a journey-based search) or only the first leg (a leg-based search). A leg-based round-trip or multi-city 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 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 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 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 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.