Quote API

An integral part of a flight integration is the quote API as this is the way we obtain live price and availability information from your server.

The quote API should be able to do the following:

• Return prices within a maximum of 30 seconds, and ideally within 10 as every extra second degrades the user experience.
• Provide the final price in the currency of the respective market. The final price shown on the website and the one returned by the API should be identical.
• Appropriately signal error messages to identify when a given flight is not available or that a route is not serviced by the 3rd party website.
• Provide the price in the same currency as is displayed on the provider website (this improves the price accuracy)
• Return Prices & Flights information in a single request (rather than multiple separate requests for each quote) – preferred

API Requests

For flight search requests, we are able to provide your API with the following information:

• Origin (IATA format) for each flight segment
• Destination (IATA format) for each flight segment
• Flight date for each flight segment
• Cabin Class
• Number of passengers (adults, children and infants): please also, provide us with the Age Group Brackets that are supported on your end (example: Adults - 12 above, Children 2-12, Infant - 0-2)
• City indicator - if your server accepts IATA city codes
• List of airports/cities and dates for multi-city searches (please note, we do not support non-airport locations)

The requests to your server can be HTTP GET or POST requests. Please include working examples and API documentation to explain the parameters in detail. For example for cabin classes, a mapping of the code used in API and the actual class service is required.

Along with working examples, we would also need the following items from you.

1. The max request count per second (API Rate Limit)
2. Age Group Brackets as mentioned above
3. Booking Horizon (0-330 days): How far advanced can the traveller book a ticket?

Search Type configuration to be used for API Requests

• Same as per user search (default option): Skyscanner will always make quote requests to the partner exactly matching the traveller search. Examples:
  • When a traveller searches for LHR, LHR will remain as LHR in the API request
  • When a traveller searches for LON, LON will remain as LON in the API request

• Forced City Searches: Skyscanner will always make quote requests to the partner at the city level. For a search performed at the airport level, Skyscanner will find the city containing the airport, and the quote request will be performed using this. Any results returned by the partner for an airport search not matching the airport will be entered in the quote cache, but not displayed in our search results. Examples:
  • When a traveller searches for LON, LON will remain as LON in the API request
  • When a traveller searches for LHR, LHR will be replaced by LON in the API request

• Forced Airport Searches: Skyscanner will always make quote requests to the partner at the airport level. Skyscanner will find all airports within the city according to the flight's geo hierarchy and produce a quote request for each. For return-based partners on return searches, only quote requests returning to the same airport will be produced (meaning return-based partners cannot have different-airport returns at all, however, leg-based partners can have these constructed). When the rule requires timetable entries, this will be honoured in the airport expansion (i.e. if a LON search is performed, a force-airport partner with a timetable-restricted rule and with timetables from LHR will only be queried for LHR) Examples:
  • When a traveller searches for LHR, LHR will remain as LHR in the API request
  • When a traveller searches for a city with multiple airports (like London or New York), a request will be created for each airport-airport combination between those two places, assuming that the partner is configured to be queried for all of those airport combinations. That means that the volume of API calls might get increased, which is why we avoid using this configuration in most situations.

Caveats

1. We do not support Forced Airport Searches for OTAs.
2. For the Forced City Searches, we use IATA City Codes. 

API Responses

The response from your server should include the following information:

Per segment:

• Origin (IATA format)
• Destination (IATA format)
• Departure time
• Arrival time
• Marketing carrier
• Operating carrier (if different from marketing carrier)
• Flight number
• Cabin class

Per itinerary /quote:

• Base price
• All taxes and fees (including card fees, if present)
• Deeplink URL (if possible)
  • It is recommended to include deeplink URL in each itinerary/quote, as you retain flexibility in case a change of URL is needed.

Additional fare information (where available, per segment or itinerary):

• Fare Basis Code (alpha-numeric characters)
• Booking Code/Fare Code/Booking Class/RBD/Reservation Booking Designator (one letter that represents the fare that the ticket is booked into)
• Fare Family Name (name of the fare family, for example, Basic Economy, Flex, or Business Promo)

Response and Error Handling

We also require the mapping of error codes and the reason for the error in the technical survey to help us to better respond when an error occurs and to assist with your debugging work we will segment different types of errors in the Partner Portal.

 

Typical response types:

• success - prices are available and returned by the API
• no flights available - request and response are successful, but there is no availability for this search. Ideally, please mark this clearly as "no flights available" or similar, rather than returning an empty response or a generic error
• bad route - the request was valid, but the origin-destination pair is not supported, please indicate that if possible as well
• other errors - bad request, wrong credentials, not authorized (in cases of IP blocking - please ensure Skyscanner IP addresses are not blocked) - if possible, please provide a list of supported errors for the engineers to map correctly