Route Configuration

To send you the most relevant quote request, we will check if you have coverage on that certain route. There are a number of ways to configure your route settings:

• Default
• Automated Updates
• Manual Configuration

In most of the cases, we would prefer to use the default options - which is open to all routes available. However, some of our partners may elect not to open all routes because of the following reasons:

• Technical Capability - Partner's server is not able to handle all traffic from Skyscanner.
• Commercial Reason - Partner has certain business requirements to follow. 

Default

Official Airline Guide

For our airline partners, it is recommended that we consume routes and timetable data from OAG. It requires no specific action from you, leave the rest to us and OAG.

No Limitations

For our OTA partners, you can elect to open all routes for search. This means that your server will get all search requests in general. No route list has to be provided in such a case, but if required, we will limit the display to only specific user markets (points of sale).

Skyscanner systems include a comprehensive system of routes and timetables from around the world. We will only query our partners' systems for a particular departure-arrival pair (route) if we know that the route is actively operated. When applied to airlines, we will check if your carrier has active flights on this route, and for Online Travel Agents, we will check their individual configuration. If no particular settings is found, all requests will be sent to our partners.

Automated Updates

FTP

For routes update via FTP, partners will provide us:

1. Credentials to access FTP server
   • Endpoint / IP address
   • Account 
   • Password
2. A file (preferably in CSV format) stored in the server which is constantly updated with latest routes data.

For airline partners, we generally expect the following fields to be included in the routes file:

Field	Description	Example
Origin	Origin Airport in IATA code	LHR
Destination	Destination Airport in IATA code	EDI
Days of Week with operation	Specify if the route has daily service	123.5.7
Schedule Starts	The date we should apply the route	2017-11-03
Schedule Ends	The date we should remove the route	2018-03-31

With this information, the output file may look like this:

origin, destination, days_of_week, date_start, date_end
LHR, EDI, 123.5.7, 2017-11-03, 2018-03-31
LHR, TPE, 1234567, 2017-10-28, 2018-03-31

For OTA partners, route data is usually configured via general route restrictions. As business requirements don't change frequently, automated updates may not be the most cost-efficient way.

API Endpoint

Some partners may prefer to offer an API endpoint rather than a FTP download, we can also support that. It is recommended to provide a RESTful API with responses in JSON or XML format.

The API response could look like this:

    {
        "origin": "TPE",
        "days_of_week": "1......",
        "destination": "SIN",
        "effective_start": "2018-07-26",
        "effective_end": "2018-09-01"
    },
    {
        "origin": "CFU",
        "days_of_week": "12345.7",
        "destination": "LGW",
        "effective_start": "2018-07-20",
        "effective_end": "2018-12-28"
    },
    {
        "origin": "IST",
        "destination": "BHX",
        "days_of_week": ".2.4.6.",
        "effective_start": "2018-08-08",
        "effective_end": "2018-08-15"
    },

The origin and destination information are mandatory for the basic level or route configuration, while all the others further enrich the context of your actual offering. 

Manual Configuration

We can also configure to allow or deny requests with certain type routes be sent to our partners.

If you would like to specify the routes you operate, you may do this by providing us with an IATA formatted list of airport-airport or city-city pairs, for example CDG-LHR. Using this method, the routes are best supplied in .csv or .xlsx format. Please discuss this with your technical account managers for details.