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.

To sign up for the Transitland Routing API beta, use your Interline account to place a new order for a Transitland API subscription. Select the Transitland Routing API - Beta plan.

The beta plan includes 1,000 free routing queries per month.

At the end of the beta period, we will announce free and paid plans.

Online vs. batch usage

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

Geographic coverage

For beta release, coverage is all current operators in the United States.

In the future, we expect to increase routing coverage to match worldwide coverage offered by other Transitland v2 APIs.

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 beta release of 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.
  • Compatible APIs: Transitland Routing API beta is released with an API endpoint that is 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 a beta release and 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.
  • GTFS Realtime:
    • Transitland Routing API doesn't make use of GTFS Realtime TripUpdates or VehiclePositions.
  • Performance:
    • Users of the beta may intentionally be slowed or rate limited in their use.

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 beta release of 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

timestringrequired
Time of departure (or arrival if arriveBy is true) in local time. Format: HH:MM or HH:MM:SS, on a 24-hour clock. A 12-hour time such as 8:30am is rejected.

Example:08:30

datestringrequired
Date of travel in YYYY-MM-DD format. MM-DD-YYYY is also accepted, with the month first.

Example:2026-08-17

arriveByoptional boolean
If true, the specified time and date are treated as the target arrival time at the destination rather than the departure 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:falseExample:false

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

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.