Flex APIs Version Policy

FlightStats aims to provide a rich and responsive API platform that is free from unexpected disruptions. Our customers want API products that are continuously improving, but also have stable and predictable formats. We aim to please everybody with a versioning scheme for the Flex APIs that offers both a dependable format as well as incremental improvements.

Long Term Support Fields

When a new version of a Flex API is released from BETA, the initial fields in the response are considered Long Term Support Fields and by default the APIs return only LTS fields. When we have opportunities to improve an API version by adding new data, we will add new non-LTS fields. Non-LTS fields will only be returned if they are specifically requested with an extendedOption parameter. The inclusion of the non-LTS fields will not affect the visibility or content of the LTS fields.

Here is an example of how the non-LTS fields are requested:

Fields Requested Example URL
Only Long Term Support fields https://api.flightstats.com/flex/airports/v1/airports/all
LTS & Non-LTS Fields https://api.flightstats.com/flex/airports/v1/airports/all?extendedOptions=includeNewFields

When a new API version is released, we make sure that we lock it down for long-term support so that you can depend on it into the future. Customers with parsers that expect strict adherence to our published documentation (WSDL, XSD, etc) will appreciate this. Customers with more flexible parsers that are tolerant of additive changes will have the opportunity to request the new non-LTS fields and stay on the cutting edge.

New Versions

When we improve an API beyond simply adding data, we will release an entirely new version. The new version of the API will have its own set of LTS and non-LTS and will evolve separately from the previous version.