Skip to content
Documentation

Transit routing (OTP-compatible)

Last updated

The Transitland Routing API plans routes from an origin/start location to a destination/stop location by transit and other modes of travel.

The Transitland Routing API is powered by the same archive of GTFS archives as the other Transitland v2 APIs. Users can combine itineraries from the Transitland Routing API with queries performed against other Transitland v2 APIs.

For definitions of journeys, itineraries, and legs, see Journeys and itineraries.

Online vs. batch usage

The public Transitland Routing API is intended for "online" purposes such as interactive web or mobile applications.

Coverage

The Transitland Routing API plans itineraries from static GTFS trips and schedules and, where supported, from GTFS Realtime TripUpdates:

DataCoverage
Static GTFS schedulesAll current operators in the United States
Real-time trip updatesOperators in the San Francisco Bay Area

Outside real-time coverage, itineraries follow the published schedule. For how the transit graph is built and updated, see Routing graph and costing models.

In the future, we expect to expand static coverage to match the worldwide coverage of other Transitland v2 APIs, and to add real-time coverage for more operators and regions.

Modes of travel

Transitland Routing APIs support travel by transit and walking.

In the future, additional modes of travel may be supported.

Features and benefits

The Transitland Routing API provides the following features and benefits:

  • Broad coverage in one routing engine: Transit routing across all locations in the United States where Transitland has GTFS source feed coverage (to be expanded worldwide in the future). No need to maintain separate routing engines for each metro region.
  • Rapidly updating schedules: When the Transitland platform receives new versions of source feeds, the new routing graph tiles are rapidly created behind the scenes. Transitland Routing API switches to using the new source feed version's service schedules within minutes. No need to wait hours or days for the routing engine to rebuild.
  • Real-time trip updates: Where an operator's GTFS Realtime TripUpdates are supported, itineraries use the predicted departure times, and each transit leg reports its delay. Use ignoreRealtimeUpdates to plan from the schedule alone. See Coverage for the operators currently supported.
  • Compatible APIs: Transitland Routing API provides an endpoint compatible with OpenTripPlanner. We may add additional compatibility modes in the future, such as a Google Directions API compatibility endpoint.

Known limitations

Transitland Routing API is under ongoing development. The following are known limitations:

  • Journey itineraries:
    • Pedestrian legs include a shape, origin, and destination, which is sufficient for plotting on a map; pedestrian legs do not include detailed street names or maneuver routing for narrative instructions.
    • Itineraries do not include fares.
  • Stops and routes:
    • pickup_type or drop_off_type > 0 not supported.
    • continuous_pickup and continuous_drop_off not supported
    • Loop routes not well supported.
  • Timezones:
    • Trips spanning multiple timezones are not well supported.
  • Transfers:
    • Transitland Routing API doesn't make use of transfers.txt when calculating transfers.

The following are previous limitations that have since been resolved:

  • Transfers after midnight are now supported.
  • block_id in trips.txt is now used when calculating transfers.

OTP-compatible API endpoint

The Transitland Routing API provides an endpoint that supports the main request options and response type as OpenTripPlanner's plan REST API.

Software libraries designed to work with the OTP REST API will also likely work with the Transitland Routing API.

OpenTripPlanner (OTP) is an open-source transit trip planner. No code from the OTP project is used to power the Transitland Routing API.

Endpoint

Submit requests to

https://transit.land/api/v2/routing/otp/plan

Requests may use GET or POST methods.

Transit routing or stop departures?

This endpoint plans a journey from an origin to a destination. It selects stops, routes, and transfers, and returns itineraries with walking legs and timings.

To list departures from a known stop, use the REST API stop departures endpoint. It returns the trips serving a stop in a time window, with real-time estimates where a feed provides them.

Request and response

GEThttps://transit.land/api/v2/routing/otp/plan

Returns transit and walking route itineraries between the specified origin and destination. The endpoint accepts parameters to control departure/arrival times, walking distances, transit leg limits, transfer penalties, and more.

Request

fromPlacestringrequired
Origin in lat,lon format.

Example:37.7757,-122.4198

toPlacestringrequired
Destination in lat,lon format.

Example:37.7857,-122.4064

timeoptional string
Time of departure (or arrival if arriveBy is true) in local time at the origin (at the destination if arriveBy is true). Format: HH:MM or HH:MM:SS on a 24-hour clock, up to 48:00:00. A time past 24:00 continues into the next day, so 25:30 is 01:30 the day after. A 12-hour time such as 8:30am is rejected. When time, date and relative_date are all omitted, the request plans from now; time alone is that time today. Required when date or relative_date is given, and when arriveBy is true.

Example:08:30

dateoptional string
Date of travel in YYYY-MM-DD format. MM-DD-YYYY is also accepted, with the month first. Defaults to today in the time zone of the origin (of the destination if arriveBy is true). Requires time. Cannot be combined with relative_date.

Example:2026-08-17

relative_dateoptional string
Date of travel relative to today in the time zone of the origin (of the destination if arriveBy is true), instead of date. TODAY, YESTERDAY or TOMORROW. MONDAY through SUNDAY is the next such day, or today if today is that day. NEXT_MONDAY through NEXT_SUNDAY is the next such day after today. Also accepted as relativeDate. Requires time.

Allowed:TODAY, YESTERDAY, TOMORROW, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY, NEXT_MONDAY, NEXT_TUESDAY, NEXT_WEDNESDAY, NEXT_THURSDAY, NEXT_FRIDAY, NEXT_SATURDAY, NEXT_SUNDAYExample:TOMORROW

arriveByoptional boolean
If true, the specified time and date are treated as the target arrival time at the destination rather than the departure time. Requires time.

Default:falseExample:false

maxItinerariesoptional integer
Maximum number of itineraries to return. Also available as numItineraries.

Default:10Example:3

maxWalkingDistanceoptional number
Maximum walking distance (in meters) allowed from the origin to the first transit stop or from the last transit stop to the destination. Also available as maxWalkDistance.

Default:800Example:800

maxTransferWalkingDistanceoptional number
Maximum straight-line distance (in meters) allowed for transfers between stops.

Default:400Example:400

walkingSpeedoptional number
Walking speed in meters per second. (Fixed at 1.0 in the beta release.)

Default:1Example:1

minRideLengthoptional integer
Minimum duration (in seconds) of a transit leg.

Default:120Example:120

maxKoptional integer
Maximum number of transit legs allowed in an itinerary.

Default:8Example:8

maxTripTimeoptional integer
Maximum total itinerary time (in seconds).

Default:14400Example:14400

transferTimePenaltyoptional integer
Amount of padding to add (in seconds) when considering a transfer. For example, when alighting from the end of the first transit leg and walking to the departure stop for the next leg, only transfers to new trips departing at least 120s from that moment will be considered

Default:120Example:120

useFallbackDatesoptional boolean
Use "fallback" service dates if the requested date is outside the service period of a given feed. For instance, if a feed only contains service from 2023-01-01 through 2023-01-31, and a date of 2023-05-01 is specified, an equivalent weekday (in this case, Monday) will be selected within the valid service range, such as 2023-01-09.

Default:trueExample:true

includeWalkingItineraryoptional boolean
Always include a walking-only itinerary alongside transit results.

Default:falseExample:false

fallbackWalkingItineraryoptional boolean
Return a walking-only itinerary if no transit trips are found.

Default:falseExample:false

allowWalkingItineraryoptional boolean
Automatically include a walking-only itinerary if the origin and destination are within the maximum walking distance.

Default:falseExample:false

includeEarliestArrivalsoptional boolean
Include a table of the earliest arrival times at stops during trip planning.

Default:falseExample:false

useTargetStopPruningoptional boolean
If true, stops that cannot improve the final arrival time are ignored. Set to false to include all stops, useful for generating isochrones.

Default:trueExample:true

ignoreRealtimeUpdatesoptional boolean
If true, the plan uses the schedule alone, without the realtime trip updates the server applies.

Default:falseExample:false

realtimeOnlyoptional boolean
If true, the plan rides only trips that a realtime trip update matches, whatever the update predicts. Cannot be combined with ignoreRealtimeUpdates.

Default:falseExample:false

debugRealtimeoptional boolean
If true, each transit leg whose run a trip update matched also carries realtimeDebug, the update's trip descriptor, and each of its stops carries its scheduled departure, the source of its departure, and the stop time update placed there.

Default:falseExample:false

Response

earliestArrivalsarray of objects
Earliest arrival time at each reachable stop. Present only when includeEarliestArrivals is true.
earliestArrivals.earliestArrivalinteger (int64)
Earliest arrival time at the stop, as Unix time in seconds.
earliestArrivals.latnumber (double)
Latitude of the stop.
earliestArrivals.lonnumber (double)
Longitude of the stop.
earliestArrivals.stopIdstring
GTFS stop identifier from the source feed.
earliestArrivals.stopNamestring
Name of the stop.
earliestArrivals.stop_codestring
GTFS stop code, when the feed provides one.
planobject
plan.dateinteger (int64)
Epoch timestamp (in milliseconds) representing the date of the plan.
plan.fromobject
plan.itinerariesarray of objects
Candidate trips, best first. Empty when no trip was found.
plan.toobject

See the Routing Platform overview for API access and the machine-readable schema.