Moovit Public Transit APIs

Moovit exposes a set of APIs tuned to support efficient and easy integration with any customer and to provide the best experience for users. We would welcome the opportunity to refine the specifications better to match your use case. These APIs have a thin nature in order to answer focused questions with very short response times. Some of these APIs also assume a user context, which will allow rolling various ID’s (such as itinerary ID) between requests.

Since Moovit’s data is split into supported metro areas, the various API methods return data either from the metro that was explicitly specified, or from the metro deduced from the user’s location. The complete and updated list of supported countries can be found here. From within this page it is possible to drill-down into a specific metro area. In order to receive a metro ID from this list, which can be used within the MOOVIT_METRO_ID request header (described below), please contact your Moovit account manager.

The HMAC Authorization methodology requires an Authorization header to be sent, and the signature will be generated and validated using the license key, acting as a shared secret between Moovit and 3rd party API user.

A request that passes such validation will be processed, and a request that fails such validation will be rejected and will potentially trigger a security alert.

The digital signature is based on the following data elements:

• Request payload - the precise and entire JSON sent in the request body
• Nonce - a random 255 characters string
• API secret key - the license key shared from Moovit
• Timestamp - current UTC time in Java format (milliseconds since 1/1/1970)

The flow for generating the signature is as follows:
1. Generate the Nonce
2. Concatenate [Timestamp]:[Request payload]:[Nonce]
3. Generate a HMAC signature (use SHA256 algorithm).
Specify the concatenated string as the HMAC payload and the API secret key as the HMAC key.

The following headers should be sent as part of each request:

Authorization: hmacauth [signature]:[Nonce]:[Timestamp]
API_KEY: public api key provided by Moovit

Example:

Assume that an API call is made where the request payload is {“x”:1,”y”:2}
The API secret key for this example is ABCDEF123456, and the current timestamp is 1234567890.
The flow for generating the signature will be as follows:

• Generate Nonce: “qwerty” (assume this is 256 characters long)
• Generate concatenated value: 1234567890:{“x”:1,”y”:2}:qwerty
• Generate the hash:
• Hash = hmac(alg: SHA256, value: 1234567890:{“x”:1,”y”:2}:qwerty, key: ABCDEF123456) For the sake of this example, let’s assume the result of the signature is “XYZ”.
• The following HTTP header is sent as part of the request (along with the API_KEY header): Authorization: hmacauth XYZ:qwerty:1234567890

All of the APIs receive a set of HTTP headers:

• MOOVIT_METRO_ID An optional header specifying the required metro to search in, overriding the user’s location. This allows, for instance, for a user from LA to search data in NYC.
• USER_LOC The user location in the format of “(lat, lon)”, in degrees.
• MOOVIT_PROTOCOL_VERSION The version of the protocol of the current request (for backwards compatibility purposes). If not specified, the latest version will be used. Current protocol version is 5.1.0.0
• API_KEY: Public api key provided by Moovit
• Authorization: hmacauth [signature]:[Nonce]:[Timestamp]

One of MOOVIT_METRO_ID / USER_LOC is required.

In general, and unless otherwise stated, it is not allowed to cache any results from the APIs described in this document. All APIs return a standard cache-control directive (via response HTTP headers). This is done either via a cache-control header with one of no-cache or max-age directives, or an ETag header. By using Moovit’s APIs, callers agree to adhere to these cache control headers.