Skip to content
English
  • There are no suggestions because the search field is empty.

API Documentation

We provide two paths to API Documentation which provides details on routes/endpoints, and data models.

Path 1: Via UI

Once logged into the UI, select user in the top right corner, as indicated below:

 

Navigate to 'Api documentation', and select 'Open API documentation' as shown below.

 

Within you will find an overview of defined API routes, as well as the list of data models used by the documented API routes as request or response bodies.

At the bottom of the page you will notice a Notes section which outlines important query parameters.

Path 2: Via Web Link

No UI access, no problem. Review the alternative documentation via this link: 

Alternative API Documentation

Contact support+api@railstate.com to have a token generated.

 

Important information: 

The export API serves to sync a user's train sightings database with our database. Each export API request provides a list of train sightings that the user needs to patch in their local database. If one of the sightings in the patch has a sighting id that the user already has in their database, then they need to override the data of that sighting. Meaning you would want to overwrite the sighting parameters according to the latest provided data, if the same sighting id is received another time (vs keeping a duplicate on sighting ID). 
The main purpose of the full_sightings API route is for exporting all the train data and for keeping a local train database in sync with our data. This is the reason why the data are sorted by the last modification time. The idea is that the user is keeping a local copy of the train data and asks the API for changes that happened since their last sync.

In querying the full_sightings route with last_modification_time_from set to the time of the last sync, using the nextRequestLink in the API response to paginate through all the data. This will get data about the new train sightings and the sightings where the data were updated.

Users should also use the deleted_sightings API route with deletion_time set to the time of the last sync, to get all the sightings that were deleted since the last sync. (Records are deleted when, as an example, partial train sightings are merged, etc). It is again necessary to paginate through all the results using the nextRequestLink. 

As an option, if you are not interested in all train data, you can use the sensors query parameter to filter for specific sensor location data only, or use detection_time_from and detection_time_to to filter by detection time.

Searching for specific car types (and some other attributes) is not supported by the public API as of now, but is something we are looking to do within the roadmap. If you have specific feedback on different ways in which you would like to query the data please do let us know as you continue the review.

For technical support related to the API, please email support+api@railstate.com