The Traxo API can be used to access travel information on behalf of Traxo members.


Current API Version: v2 (November 1, 2013)

All Traxo API endpoints include a version identifier as part of the url.


Within a given version, clients can be assured that no backwards incompatible changes will be made under normal circumstances. Additional response parameters may be present at any time (see New / Experimental / Unsupported Fields section below).

Data Types and Values

Content Type

The Traxo API serves responses with the "application/json" Content-Type.


JSON (as defined by ECMA-404 The JSON Data Interchange Standard) is supported by every modern programming language and application framework.

API responses may take the form of a JSON object (a collection of name/value pairs) or a JSON array (an ordered list of values) as defined by the standard.

A JSON value can be a string in double quotes, or a number, or true or false or null, or an object or an array.

API responses may contain parameters with null or empty string values. These values indicate an absence of data and should be handled as such by the consumer of the API response.


Traxo resources are typically identified using 64-bit integers delivered as string values.

While not guaranteed, Traxo resource IDs are typically unique globally for a given resource type.

Traxo resource IDs are generally time ordered and not sequential.

Examples: "534619485683827958" "534619485683828212"

See the Traxo API definitions for details and examples specific to each resource.

Dates and Times

All dates and datetimes comply with the ISO8601 standard. We remove the timezone offset specification for dates and datetimes that are assumed to be local. Many of our travel data suppliers report datetimes as local.


2008-10-20T11:45:25+0000 - A datetime with zero timezone offset (i.e. this is UTC)
2008-10-20T11:45:25 - A local datetime
2008-10-20 - A local date (no time is specified), typical for hotel segments 
When available, we may include a timezone identifier (string) field that can be interpreted by most modern programming languages to determine daylight savings time and normal offsets from UTC.



Error Responses

When errors are encountered with a given request, the response will include an appropriate HTTP response code, an error code string, and an error description in English. The documentation for each method will show error codes that could be expected.

Example HTTP Response header:

401 Authorization Required
Response body:
    "error_description":"The access token was not found."

Common Error Responses: Common OAuth-related Responses:

Validation Error Responses

When submitting data to the API, fields that do not pass internal validation checks will trigger a `validation_error` response. This response will usually contain a fields object with a key for each input parameter that failed validation and one or more textual messages for each key.

    "error_description":"Validation failed",
    "fields": {
        "origin": [
            "Invalid origin airport"

HTTP Response Codes

We try to send an appropriate HTTP response code so you can avoid the overhead of parsing the response if you don't need to. Examples:

New / Experimental / Unsupported Fields

New fields may be added to API responses within a fielded version as business and market needs dictate. Developers should ensure that their integrations graceful handle these additional fields.

Any field name with a leading underscore should be considered experimental and unsupported and may be removed at any time.

These fields are used to test new features and concepts or to support debugging and troubleshooting efforts.

If you see one of these that you really want or need, send us a message: