---
title: "Retrieve the list of requirements of the timetable (invalid trains are ignored)"
method: GET
path: "/timetable/{id}/requirements"
tags: ["timetable"]
---

# Retrieve the list of requirements of the timetable (invalid trains are ignored)

`GET /timetable/{id}/requirements`

## Path parameters

- `id` integer, required

## Query parameters

- `page` integer
- `page_size` integer
- `infra_id` integer, required
- `electrical_profile_set_id` integer

## Response `200`

The paginated list of timetable requirements

- object — Statistics about a paginated editoast response Provides the pagination settings issued in the request alongside a few convenience fields useful to navigate the paginated results. # Expected usage This struct is meant to be used and flattened in the response of a paginated query. ``` #[derive(Serialize, ToSchema)] struct MyPaginatedResponse { #[schema(flatten)] pagination: PaginationStats, result: Vec<MyData>, // any other field that makes sense in a paginated response } ``` We named the data field `result` to cope with the old pagination schema which enforced this name. For new paginated responses, the field name is up to your imagination :)
  - `count` integer, required — The total number of items
  - `current` integer, required — The current page number
  - `next` integer, nullable, required — The next page number, if any
  - `page_count` integer, required — The total number of pages
  - `page_size` integer, required — The number of items per page
  - `previous` integer, nullable, required — The previous page number, if any
  - `results` CoreTrainRequirementsById[], required
    - `routing_requirements` CoreRoutingRequirement[], required
      - `begin_time` integer, required — Time in ms since a reference point that depends on which struct embeds this one: - in `TrainRequirements` & `TrainRequirementsById` (conflict detection & timetable requirements): a request-wide origin shared by all trains, `work_schedules` and the response (`1970-01-01T00:00:00Z` for calendar timetables, the timetable start for hourly ones); - in `CompleteReportTrain` (simulation results): the train's own `start_time`.
      - `route` string, required
      - `zones` CoreRoutingZoneRequirement[], required
        - `end_time` integer, required — Time in ms since a reference point that depends on which struct embeds this one: - in `TrainRequirements` & `TrainRequirementsById` (conflict detection & timetable requirements): a request-wide origin shared by all trains, `work_schedules` and the response (`1970-01-01T00:00:00Z` for calendar timetables, the timetable start for hourly ones); - in `CompleteReportTrain` (simulation results): the train's own `start_time`.
        - `entry_detector` string, required
        - `exit_detector` string, required
        - `switches` object, required
        - `zone` string, required
    - `spacing_requirements` CoreSpacingRequirement[], required
      - `begin_time` integer, required — Time in ms since a reference point that depends on which struct embeds this one: - in `TrainRequirements` & `TrainRequirementsById` (conflict detection & timetable requirements): a request-wide origin shared by all trains, `work_schedules` and the response (`1970-01-01T00:00:00Z` for calendar timetables, the timetable start for hourly ones); - in `CompleteReportTrain` (simulation results): the train's own `start_time`.
      - `end_time` integer, required — Time in ms: see begin_time
      - `zone` string, required
    - `train_id` string, required
    - `train_name` string, required — ID that can be used to find the train in tools other than OSRD. Used in debug traces.

---

[API](https://skmtc.net/openrailassociation/apis/osrd-editoast.md) · [All operations](https://skmtc.net/openrailassociation/apis/osrd-editoast/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/openrailassociation/osrd-editoast/versions/1840dbbd64ac/schema)