To get an API key, use your Interline account to order a Transitland API plan: Explorer for free, non-commercial use, or Pay As You Go for commercial use. See plans and pricing for each plan's quota and pricing.
Documentation
Transit routing (OTP-compatible)
Last updated
Available onExplorerPay As You GoHobbyist/AcademicEnterprisePlans and pricing
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:
| Data | Coverage |
|---|---|
| Static GTFS schedules | All current operators in the United States |
| Real-time trip updates | Operators 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
ignoreRealtimeUpdatesto 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_typeordrop_off_type> 0 not supported.continuous_pickupandcontinuous_drop_offnot 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.txtwhen calculating transfers.
- Transitland Routing API doesn't make use of
The following are previous limitations that have since been resolved:
- Transfers after midnight are now supported.
block_idintrips.txtis 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.
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
Request
timeoptional string- Time of departure (or arrival if
arriveByis true) in local time at the origin (at the destination ifarriveByis true). Format:HH:MMorHH:MM:SSon a 24-hour clock, up to48:00:00. A time past24:00continues into the next day, so25:30is 01:30 the day after. A 12-hour time such as8:30amis rejected. Whentime,dateandrelative_dateare all omitted, the request plans from now;timealone is that time today. Required whendateorrelative_dateis given, and whenarriveByis true.Example:
08:30 dateoptional string- Date of travel in
YYYY-MM-DDformat.MM-DD-YYYYis also accepted, with the month first. Defaults to today in the time zone of the origin (of the destination ifarriveByis true). Requirestime. Cannot be combined withrelative_date.Example:
2026-08-17 relative_optional stringdate - Date of travel relative to today in the time zone of the origin (of the destination if
arriveByis true), instead ofdate.TODAY,YESTERDAYorTOMORROW.MONDAYthroughSUNDAYis the next such day, or today if today is that day.NEXT_MONDAYthroughNEXT_SUNDAYis the next such day after today. Also accepted asrelativeDate. Requirestime.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
timeanddateare treated as the target arrival time at the destination rather than the departure time. Requirestime.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 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
Response
See the Routing Platform overview for API access and the machine-readable schema.