We can’t provide SIPP codes, is this going to be a problem?
Skyscanner urges all providers to use the SIPP suggested standard, however if for some reason you are not able to provide these codes, it is necessary that you provide us with a way to generate or map your rates to the closest possible SIPP code mapping. If these are not close enough, or are often incorrect, your rates may not be shown on our website and will be discarded due to poor accuracy.
What format should we send you our logos in?
Logos should be provided in the following dimensions (pixel) in PNG format:
- 1x 120x60
- 1x 120x30
- 1x 60x30
- 1x high-quality PNG (640dpi)
- 1x SVG (sRGB colour space)
Will it be necessary for you to make live bookings on our site?
We should not need to make any live bookings through a provider’s site. However, if this is required for any reason, communication and warning will be given beforehand in order to assure the request can be flagged and deleted before a booking is made.
Is it necessary for you to access our test environment in order to integrate our API?
We do not need to access a test environment if a production environment is ready and available. All final tests performed on an integration will have to happen on a live environment, where deeplinking and final prices exist.
We do not have the same level of time granularity that Skyscanner provides, will this be an issue?
Where a time is not available in your system (for example you only allow a booking on the hour but Skyscanner allows a user to search every half hour) we will not include those rates within our search results.
We use a (SOAP/XML/JSON/YAML/GraphQL) based API is this ok to use?
The format of the API is not an issue assuming that the documentation is well maintained and up to date. Each integration into the Skyscanner website is bespoke and we can work with your API regardless of its format.
We have a lot of extra charges and optional charges, should these be included in the rates returned from our API?
Your API should return all optional charges and either a total charge including all mandatory taxes and charges combined into a total sum, or all charges and taxes separately with instructions on how to construct the total rate. We strive to match the same price as a providers booking page, any variances are considered a price inaccuracy and will be taken very seriously.
What extra information can we send about our Rates?
Please see the documentation here
Why Do I have to fill out the Pre-integration Survey?
By filling out the pre-integration survey, you provide us with all the important and necessary information to start and complete your integration. On average a full and complete survey can cut a significant amount of time from the integration. For example, an integration that may usually take 6 weeks to complete could be completed in 2. All questions asked in the survey are necessary to assist with the integration and are there to make the process as quick as possible.
What information does an API need to include?
An API should include, at least, a call to retrieve all locations for a provider, with a mapping of each internal location ID to an IATA code or Lat/Long value. The API should also provide a method for requesting the relevant information for all rates for a specific location and provider. The minimum rate information your API should meet is below:
- Total price of the rental quote (including ALL mandatory charges and taxes) for all available cars within a location.
- Currency of the total price returned with each car
- 4 letter SIPP code mapping of each car
- Car/Vehicle Name of each car
Which languages and currencies should our API support?
This depends on the users market. Ideally an API will support all of our markets, languages and currencies that Skyscanner support on our front page. However we understand that this is difficult to provide therefore the minimum requirements necessary are that an API returns the result in the currency/language for the respective pick-up location and/or user market. For example, a vendor renting out cars in Russia to a user in Greece should give us the price in RUB and or EUR, sell rates in RUB and or EUR and support Russian and Greek in the deeplink and on their website.
Is there a minimum set of messages we need to support in order to be compatible with Skyscanner?
We require the ability to request all the locations for a provider and the ability to request a complete list of rates for each location. If you already have calls that match those descriptions then your message set is probably complete enough to be integrated. If you are unsure about your APIs abilities please contact your commercial account manager to set up a technical call. If you do not currently have an API please see the FAQ regarding a lack of API
We currently don’t have an API is there any support or a standard we can use to build it?
If you do not currently have an API you can use the Open Travel Standard as a base and work from there. We are not currently able to provide any official support in developing an API but our experienced developers will be able to work with you in implementing the API with the Skyscanner website. In order to integrate with Skyscanner only the following request and responses need to be implemented: - OTA_PingRQ 10 - OTA_PingRS - OTA_VehLocSearchRQ - OTA_VehLocSearchRS - OTA_VehLocDetailRQ - OTA_VehLocDetailRS - OTA_VehAvailRateRQ - OTA_VehAvailRateRS - OTA_VehResRQ - OTA_VehResRS - OTA_ErrorRS 11 Deeplink
What is a Deeplink?
We require that once a user has selected a quote, they are redirected to the provider’s site, passing all the relevant search criteria. We define this as a deeplink, and there are three possible depths:
1. Booking Page: The final result before a user has to enter personal details and complete the booking, this is the preferred redirect level.
2. Results View: The step after selecting a data time and location that shows all of the available cars and rates.
3. Home Page: The home page of your company’s website.
Minimum depth required - Results View or Booking Page. If the deeplink fails for any reason we will default users to the homepage
Our API does not provide a complete deeplink in its response. Is this an issue?
We must have a way to deeplink to results but if you are not able to provide a pre-built redirect then it is acceptable for you to provide us with instructions for generating a working deeplink.
Regarding passing the necessary booking criteria from Skyscanner to our booking page, will this be done via the URL query string parameters?
We can do both:
1. via GET method: this is passing the parameters as query string
2. via POST method: this is passing the parameters as form fields 12 Locations
What counts as a location?
A location is a branch or office where a user can hire and drive a car from. This could be in a terminal, a downtown location or a car mall.
We don’t provide locations through our API will this be an issue?
Skyscanner Carhire is currently working to automate the location process in order to update and provide our users with your most up-to-date offices and branches. As part of this automation process we require an API method to request them, this way we can actively pull changes with the minimal amount of work from our partners. If you are not currently able to provide locations using an API, and have no plans to do so in the future please contact your commercial account manager.
What information about locations should we provide to Skyscanner in order to have our offices included in a search?
The minimal information needed in the process of updating locations is a mapping of all of a company’s internal office ID's: -
- To Latitude/Longitude coordinates and country code for non-airport locations
- To IATA codes for airport locations and country code for airport locations This will provide the most basic of functions and show your rate, but this will not allow us to display a map and we strongly suggest that you also provide:
- An address localized to the destination market.
- An identifier stating whether a location is a downtown or airport based location.
We don’t currently have any information on locations, can we define our own location codes such as Sydney = 1, Melbourne = 2 or is there a standard we should follow?
It doesn't matter what format your internal location codes are in as long as you provide us with a mapping from that internal code, to either Lat/Long values or IATA based values.
In some cases we have multiple locations for the same city (e.g. Sydney City, Sydney Airport), can each of these have a separate location code?
Each location must have a separate unique identification code in order for us to provide accurate results. if you have more than one office per city, please provide each one with an individual location code. We are able to tailor the results if there is too large a number of results within a city. If you have a preference please contact your commercial account manager.
If you have any questions that are still unanswered feel free to reach out to our Partner Services team by submitting a ticket via our partner support page