Skip to main content

Route Configuration

Updated

We will set up and check your route coverage to send you the most relevant quote requests and avoid unnecessary or wasted API calls.

 

Partners find it convenient to manage their route coverage for reasons such as:

  • Technical capabilities - Your servers are not able to handle all traffic from Skyscanner. If your quote API imposes rate limits, please keep this in mind when choosing a route configuration. We are currently not able to regulate the number of requests to an API directly, but we can make changes around the integration that will directly impact the number of requests. This includes the amount of configured routes and available markets.

  • Commercial reasons - You have certain business requirements to follow. 

 

Please note that Skyscanner systems include a comprehensive set 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.

We will afterwards check your individual configuration. All requests will be sent to you if no particular settings or restrictions are found.

 

Having that said, there are several ways to configure your route coverage and they may combined depending on your needs:

  • OAG

  • Automated updates

  • Manual configuration

  • No limitations

 

Official Airline Guide (OAG)

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

Please note that we get updated data from OAG on a daily basis. We are also constructing indirect itineraries based on that data.

Lastly, it is important to highlight that the airline partner is responsible for ensuring their routes are up-to-date. This will be between you and OAG.

 

Automated updates

Automated updates are a way to make sure that your route feed is up to date and in sync. Ideally, OAG routes information is combined with automatic updates for redundancy.

As a default, our automated updates run once a day. Updates can be configured to run more or less frequently, based on how often these are made available at your side. For example, updates can run every 3 days a week or once a day.

FTP folder

For routes update via FTP, please provide us with:

  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. Example 1 = Monday and 7= Sunday

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, 2024-11-03, 2024-03-31
LHR, TPE, 1234567, 2024-10-28, 2024-03-31

 

API endpoint

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

An example API response could look like this:

    {
        "origin": "TPE",
        "days_of_week": "1______",
        "destination": "SIN",
        "effective_start": "2024-07-26",
        "effective_end": "2024-09-01"
    },
    {
        "origin": "CFU",
        "days_of_week": "12345_7",
        "destination": "LGW",
        "effective_start": "2024-07-20",
        "effective_end": "2024-12-28"
    },
    {
        "origin": "IST",
        "destination": "BHX",
        "days_of_week": "_2_4_6_",
        "effective_start": "2024-08-08",
        "effective_end": "2024-08-15"
    },

The origin and destination (OnD) 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 will only consider manual route configurations if you cannot use the preferred options listed above. Static files require a lot of upkeep and not enough autonomy for you to make changes quickly when needed. If you need to limit your routes and can use one of our automatic route options (API or FTP), you'll have much more control over your offerings. Please review the upper sections if you have not done that yet.

 

To keep in mind: 

  1. Manual routes can be set to either include or exclude O&D pairs. 

  2. We do support duplicate route entries. We get the earliest begin date and latest end date, combining the two rows.

  3. Providing the optional information (further details below) can make us consume your pricing endpoint more accurately. This can reduce the overall network cost for both sides. 

 

If you want to specify the routes you operate, here are the two templates you can refer to configure your routes and also a general guideline as per the attachment below. 

 

CSV input file

Examples of valid formats are:

AMS,MOW
AMS,airport,BER,city
iata,MOW,BER,city
MOW,iata,AMS,city

  • Each route should be on a separate line (1st half -> origin, 2nd half -> destination)

  • [IATA/ICAO] codes will be automatically detected

  • Preferences of [city/airport] can be overridden for an individual route node

 

JSON file

An example of valid format is:

[
    {
        "from_place": {
            "code": "LHR",
            "preference": "airport"
        },
        "to_place": {
            "code": "AMS",
            "preference": "city"
        },
        "days_of_week": ["Tue", "Fri"],
        "direct": true,     
        "date_from": "2024-05-16",
        "date_to": "2024-10-10",
    }, {
        "from_place": {
            "code": "AMS",
            "preference": "city"
        },
        "to_place": {
            "code": "LON",
            "preference": "city"
        },
        "days_of_week": ["Sat"],
        "direct": false,     
        "date_from": "2024-05-16",
        "date_to": "2024-10-10",
        "include": true,
        "month_of_year": "1, 2, 12"
    }
]

 

Required: 

  • from_place: (the departure place). 

  • to: (the destination place). 

  • code: IAIA code by default. Please let us know if you return a different geo-place system. 

  • preference: one of "airport" or "city". Please bear in mind Skyscanner only supports flight business at this moment.

 

Optional:

  • days_of_week(3 digit value. "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun") can be space separated string or list. This specifies the flight pattern of this route (by depart date).

  • date_from (in "yyyy-MM-dd" format).

  • date_to (in "yyyy-MM-dd" format).

  • month_of_year (using 1-12 to indicate Jan to Dec).

  • direct: set to true if only direct routes should be requested.

  • include: set to true to true/false to include/exclude routes.

 

No limitations

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 of implementing this.

Therefore, you can elect to open all valid routes for search. This means that your server will get all search requests. No route list has to be provided in this case, but if required, we will limit the display to only specific user markets (points of sale). You can also choose to share with us a list of unsupported airports or a list of routes that we should exclude.

Related articles