Explore the technical features and details of our APIs: Documentation

{ "items":[ {"name":"Codeshare endpoint has been removed", "descr":"The code-share endpoint has become useless in since the flights endpoint already supports looking up codeshares for a flight"}, { "name":"Changed parameter names to camelcase", "descr":"Some parameters were spelled completely in lower case in earlier version. This is not consistent with other Schiphol API's and has been changed in the current version"}, { "name":"Added query mechanism for DateTime and scheduleDate", "descr":"It is now possible to query on any DateTime field that is included in the Flight API flights endpoint. This is done by specifying a date-time range in the fromDateTime and toDateTime parameters, while specifying the name of the date-time field to be queried upon in the searchDateTimeField parameter"}, { "name":"Solved inconsistency for existing nvls query and response mechanism", "descr":"In the preceeding version of the API there was a 'nvls' query parameter defined in the Flights swagger that had no corresponding 'nvls' field in the response definition. In fact, the target data was returned in the 'AirlineCode' field, but that field wasn't mentioned anywhere in the swagger specification. In the current version 'airlineCode' is defined both as query parameter for the request and as data element in the response definition of the flights endpoint. The software has been changed accordingly. The content of the airlineCode is still the nummeric value that was also known as the 'nvls-code' before. Therefore the field is now defined as integer instead of string"}, { "name":"app_key and app_id are now headers instead of query parameters", "descr":"The app_key and app_id are included as http headers in the current version of the API. This is to comply to RESTful API standards and guidelines, and also to accomplish consistent authentication over all Schiphol API's"}, { "name":"Extended route information", "descr":"Two additional data elements are included. The 'Eu' field contains either S (Schengen), E (Europe) or N (non-Europe) to indicate the type of flight. The 'visa' field contains either true or false"}, { "name":"Removed leading zero in gate numbers", "descr":"For gate numbers below 10 a leading zero was returned in previous versions of the API. This was confusing, as these are not mentioned on other places at Schiphol airport. In the current version no leading zero's are returned. For example: '7' will now be returned instead of '07'"}, { "name":"Only numbers on baggage belt", "descr":"In the preceeding versions of the API the full name of the baggage belt was returned by the API. This was confusing, as this means additional letters may be present that are not displayed on the airport signs. For example: the API would return '2a' or '2b' while signs on the airport state '2'. In the current version the public name of the belt is returned, as it is also stated on signs"}, { "name":"Added lastUpdatedAt field", "descr":"As an aid to clients the lastUpdated field has been added to all flights. This field indicates when the last change was made to the flight data"}, { "name":"Removed schemaVersion data element", "descr":"In the preceeding verions of the API there was a schemaVersion data element present in the response of all endpoints. This was not suitable for several reasons. To start with this has no meaning for clients, as the number in this version did not actually tell anything about the API version but about a backend message schema version. Also, this field was included for each entity separately while there is only one schema version available for each backend message type"}, { "name":"Limit of three days on date(Time) query parameters", "descr":"In the preceeding version of the API there was no limit on the date-range that could be specified within a single request to the Flights API. This could lead to problems. For large date-ranges it was possible that an incomplete data-set was returned by the API due to technical limitations of one of the backend systems. In the current version only a three-day DateRange or (72 hours) DateTime-range can be queried within a single request. If you want to retrieve a larger date-span multiple queries should be used instead"}, { "name":"Changed serviceType to string", "descr":"In the preceeding versions the serviceType data element was specified as an enum. This was a bad idea, as the team that develops the API has no control over new serviceTypes being introduced. As a result the enum list in the previous swagger wasn't up to date anymore. To prevent this from happening again the field has been changed to a string. This has no direct impact on clients"}, { "name":"Various documentational changes", "descr":"Various changes have been made both to the developer portal as to the swagger specification. These have no impact on clients, but should make it easier for (new) clients to understand the API"}, { "name":"Query flights more than 21 days ahead", "descr":"In previous versions of the API no flights were returned that are scheduled for more than 21 days ahead. This limitation is now removed, meaning that all future flights which are scheduled in the flight information system can be found using the API"}, { "name":"Sorting on all objects, including nested objects", "descr":"It is now possible to sort on all objects, including nested objects. A good example of this would be sorting on the 'iatamain' object that is nested in the 'aircraftType' object within a flight. The syntax for this kind of sorting is '['+'|'-'][parent].[child]', '[parent].[child].[child]' etc. In the example above the sort field would have to be filled with the value '+aircraftType.iatamain'"}, { "name":"Added Expected Security Filter for flights", "descr":"When retrieving flight information the expected security filter is included for each flight in the 'expectedSecurityFilter' field. This field indicates which security filter (non-transfer and non-transit) passengers of the target flight are expected to use. Note that we cannot guarantee with absolute certainty passengers will actually use that security filter"}, { "name":"Added 'pier' field to the flight information", "descr":"When retrieving flight information the pier field is now available in the response message. This field will indicate from which pier a flight is planned to depart. For most flights the pier could already be deducted by clients from the gate field. However, for flights that depart either from the M or the H pier, also known as 'wait in lounge' (WIL) flights, the gate is not shown until shortly before boarding starts. In these cases the pier field allows clients to inform passengers to which pier (and thus lounge) to proceed until further notice"}, { "name":"Flight-id now provided as string", "descr":"The flight-id ('id') is now provided as string, instead of integer. Reason for this is that some clients processed the integers incorrectly. These clients rounded the number up due to known browser limitations, as a result of which these clients were not able to retrieve the flight based on id in subseeding calls"}, { "name":"New field scheduleDateTime is now available", "descr":"A new field scheduleDateTime is now available when retrieving flight information. This field is a combination of the scheduleDate and the scheduleTime, which were already present. This means the new fromDateTime / toDateTime mechanism that was mentioned earlier can now also be used to query on schedule(Date)Time"}, { "name":"Changed two elements in the dataset of the aircraftTypes endpoint to camelcase", "descr":"This impacts the fields 'iatamain' and 'iatasub', which will now be called 'iataMain' and 'iataSub'"}, ] }

{ "items":[ {"name":"Changed field ‘checkinAllocations’", "descr":"Changed ‘checkinAllocations’ field for showing airline specified check-in information"}, {"name":"Added remarks fields", "descr":"Added remarks fields for holding airline specified remarks on the check-in information"}, {"name":"Row field can be overwritten", "descr":"Row field can be overwritten with another airline specified remark and in that case the desk information isn’t shown"}, ] }

{ "items":[ {"name":"Changed field ‘baggageClaim’", "descr":"Changed the ‘baggageClaim’ field from string to a list of belts"}, ] }

{ "items":[ {"name":"Initial Release", "descr":"No info"}, ] }

{ "items":[ {"name":"Include securityEU field", "descr":"Include securityEU field in destinations result set"}, ] }