• City tla (e.g. LON)
• Airport tla (e.g. LHR)
• TRAVELfusion location id (e.g. as returned by the ResolveLocation request)
• A coordinate of the format 'lat,long' where lat and long are decimal degrees

This will be ignored unless the Type is 'auto'. In this case, the 'ResolutionTypeList' describes the order in which TRAVELfusion should assess the descriptor-type. For example, if the Descriptor is 'AMS' (which is both a city and an airport code) and the type is 'auto', and the ResolutionTypeList has 'airportcode' before 'citycode' or it contains 'airportcode' but not 'citycode', TRAVELfusion will treat the location as Amsterdam airport. If the ResolutionTypeList is omitted, then TRAVELfusion will use an unspecified sequence containing all types. However if a ResolutionTypeList is supplied, only the types in the list will be considered.

The distance in metres to search for relevant airports. If the Type is 'airportgroup', the radius will be ignored if supplied. Otherwise, the radius will be used to search around the specified location for relevant airports. All airports within the search radius will be considered. Any outside the radius will not be considered. If omitted, an unspecified default radius will be selected by TRAVELfusion.

The date and time of departure that will be requested from the supplier. Format dd/mm/yyyy-hh:mm. If the specified date/ time cannot be specifically requested using the supplier's interface, the best approximation will be chosen. In general, TRAVELfusion guarantee to return all the flights returned by the supplier on the specified day unless the supplier does not return an entire day's flights, in which case TRAVELfusion will request the specified time of day from the supplier. TRAVELfusion will not make multiple requests to the supplier for a paricular route. In some cases, TRAVELfusion may not be able to return all the flights that the supplier returns due to processing time constraints. Please ask TRAVELfusion for more details of these cases.

Specifies a range of allowed dates. If omitted, no flight results will be discarded. These filters are only used after the supplier has returned results. They are applied to the flights returned by the supplier. If caching is enabled, any extra flights that are in the cache between the discard dates will also be returned.

Format same as DateOfSearch. If supplied, any results found that depart at a time before this date will be discarded by TRAVELfusion.

Format same as DateOfSearch. If supplied, any results found that depart at a time after this date will be discarded by TRAVELfusion.

Similar to DepartDateFilter, but applied to the arrival dates of the flights.

'ReturnDates' has the same structure as 'OutwardDates'. Specifies the return journey date parameters. If Omitted the journey will be assumed to be one-way (single)

The maximum number of changes acceptable in a single leg (i.e. this limit will be applied to the outward leg and return leg separately). This value will be submitted to the supplier if they offer this functionality. Otherwise an appropriate request will be made to the supplier. Any results returned by the supplier that include more changes than the specified number will noramlly be discarded by TRAVELfusion. However in some circumstances results may still be returned that contain more changes than requested. Please contact TRAVELfusion for more information.

This will be handled similarly to MaxChanges. See the 'Travel Terminology' section of the XML Integration Guide for definitions of 'changes' and 'hops'.

The list of suppliers to query. If omitted, all available suppliers will be queried. Contains 0 or more 'Supplier' items

A supplier identifier. Please contact TRAVELfusion for a list of possible identifiers

Specifies a list of 'Operator' codes (see Results Response spec) to allow/ discard. If omitted, all results will be returned. Outward and return legs will be filtered separately.

If the value is 'select', the operators listed will be the only ones returned. If the value is 'reject', the operators listed will not be returned.

Has value 'true' or 'false'. In cases where a leg has multiple segments where there is a mix of allowed operators (allowed by this filter) and non-allowed operators, the ‘allowPartial’ flag will define whether to return these or not. (If the flag is set to ‘true’, these results will be returned.)

Specifies the list of operators to select/ reject.

Specifies an operator as a two letter operator code

Similar to RealOperatorFilter except that the filtering is based on the 'VendingOperator' instead of the 'Operator'.

Specifies the maximum time (in seconds) that suppliers should be allowed to respond in. Any supplier queries taking longer than this will be cancelled. This should be equal to the customer polling timeout - i.e. the time at which the customer stops polling for results even if some Routers are still incomplete. It will help to minimise the load on the TRAVELfusion system and the suppliers.

Must be one of the following values: "Economy With Restrictions", "Economy Without Restrictions", "Economy Premium", "Business", "First". If omitted, an appropriate default value will be used. Travelfusion will request this class or the best approximation from the supplier where possible, but may not filter the response from the supplier, so any flights returned by the supplier, but not matching the requested class may still be returned by TRAVELfusion.

Describes the travellers that will be making the journey

A traveller description

The age of the traveller. This is required because suppliers do not all use the same age boundaries to define adults/ children etc. If the traveller's age is not known then an age should be submitted that will always give the required passenger type. e.g. 30 for adults, 7 for children, 0 for infants, 90 for senior citizen. Please contact TRAVELfusion for more details

Must have value 'true'. This will save processing and bandwith usage. Each time the ResultsRequest is submitted (polled), only new results will be returned in full detail - i.e. any results that have become available since the last poll. More details of how results will be returned can be found in the specification for the 'RouterList' element in the results response.

Any customer profile information can optionally be supplied here. See the Terms Request spec for the structure of this element. All sub-elements are optional at this stage even if stated otherwise in the Terms Request spec. However some of the custom supplier parameters may affect the results that are obtained from this search. Please see 'RequiredParameterList' in the CheckRouting Response spec for more information.

If has value 'true' then a search will actually be performed. Will be assumed 'true' if omitted. In special circumstances a customer may want to submit a search request only to get a search response - i.e. no Results Request will be made. In this case the value should be set to 'false'. For example, the customer may wish to check the value of 'RequiredParameters' in the Search Response, and then resubmit the search request including the appropriate parameters. The customer may also use this feature to investigate exactly which routes and suppliers would be searched for this request, without actually requesting that the flight data be obtained from the suppliers.