Versioning

Each request URL API version is available as given below. Then client know which version is going to be use.

We may make backwards-incompatible changes also to the API at prior notice. When we do, you may need to make changes to your integration, or it'll stop working. However we will provide available period for using versions.

Version of a particular service is exposed via swagger documentation and Online documentation as well.

In the response the version will be mentioned as given below.

Swagger UI:

/docs

Swagger JSON:

/v1/api-docs

{
  "status": {
    "code": 1,
    "message": "SUCCESS"
  },
  "commonData": {
    "searchKey": "AIR03022942",
    "productCode": "A"
  },
  "data": [
  ],
  "warnings": [
    {
      "code": "validation_required",
      "documentationUrl": "api-doc/docs/troubleshoot/api-error-codes/index.html",
      "message": "Departure Time changed for EK7 2022-09-03 DXB-LHR",
      "value": "Departure Time changed for EK7 2022-09-03 DXB-LHR"
    }
  ],

    "version": "1.0.0"
}

Version Segments

{major}.{minor}.{patch}

This final version is consist of three parts which are major, minor, and the patch version.

Availability period

When release a new version of the API, the previous version will be available for xyz months. It will no longer be available or usable after that time.

Backwards-compatible changes may be added to the latest version. In case we mark parts of the API as deprecated, they'll be removed in the next API version.

Changes in versions

Backwards-incompatible changes

Generally consider the following as backwards-incompatible changes:

• Adding a new required request body or query string parameter
• Changing the name of a required request body or query string parameter
• Removing a required request body or query string parameter
• Removing an existing endpoint
• Removing any field in the response (whether required or optional)
• Restructuring of the input or output format (e.g., making a top-level field a sub-field, or changing the location of errors to be inline)
• Changing a name of a field in the response
• Changing a resource name, such as Offer or Order
• Changing a HTTP response code
• Changing type and code attributes of API errors
• Changing existing behaviour (e.g. segments that were previously returned with a default sorting order not being ordered in that way)

Backwards-compatible changes

Following as backwards-compatible changes:

• Adding a new optional request body or query string parameters
• Adding new API endpoints
• Adding new attributes to responses from existing API endpoints
• Reordering attributes in responses from existing API endpoints
• Adding a value to an existing enumeration
• Changing format or length of IDs
• Changing title or message attributes of API errors
• Adding new types of services, e.g. meals, fast track boarding, and WiFi access.
• Communicating changes All API changes are posted to our changelog. Before we make any breaking changes, we'll email details to registered users as well.

Migration guides

For each version, we will publish a migration guide from the previous version to the new one that explains the changes you need to make to upgrade your integration.