Skip to main content

Overview

Get routing options that integrate live bike-share availability. Returns multiple route alternatives:
  • Personal bike: direct cycling route
  • Docked bike-share: walk to station, cycle, then walk to the destination. Pickup and drop-off are always in the same system.
  • Docked e-bike: the same shape, from the nearest station with an e-bike available. Marked is_electric: true.
  • Dockless bike-share: walk to the bike, then cycle to the destination. One option per provider.
Behavior:
  • Alternatives more than 3× slower than the personal bike route are filtered out
  • Bike availability is fetched in real time from GBFS feeds and provider APIs
  • Assumed speeds: walking 5 km/h, cycling 15 km/h, e-bike 22 km/h
  • Maximum bike/station search radius: 1,500 m
  • Results are ordered Personal (SuperSafe first), then docked, docked e-bike, dockless

Authentication

This endpoint requires an API key. Include it in the Authorization header:
A valid user session is also accepted and grants higher rate limits.

Rate limits

Requests are rate-limited; authenticated requests are allowed a higher rate than anonymous ones. Multi-modal has a stricter limit than directions. On 429, honor the Retry-After header.

Performance

  • Typical response time: 800–1500 ms
  • Routing segments are computed in parallel

Request body

array
required
Starting point as [longitude, latitude]
array
required
Ending point as [longitude, latitude]
boolean
When omitted (recommended), the response includes both supersafe=true and supersafe=false Personal variants, collapsed to one when they are identical, plus other option types once at supersafe=true. Clients can then toggle locally without refetching. When provided, every option type is computed under exactly that regime.
number
Identifier of a saved custom route. When it resolves to a route, that route is appended as a non-reroutable final cycling segment and its details are returned in each option’s event field.
number
Destination ID for enriched destination information in the response
string
Display name for the destination (used if destination_id not provided)
string
Display name for the origin waypoint
string
Planned departure as "YYYY-MM-DDTHH:mm" with no timezone offset, interpreted in the route city’s timezone. Determines night routing (see nighttime) and which temporary road avoidances apply; nearby active or imminent closures are surfaced per option as disruptions. Omit to route for now. Unparseable values return 400.
string
Navigate-to-parking mode: "ebike" (designated rental e-bike bays) or "regular" (cycle racks/stands). The Personal option becomes cycle-to-spot + walk-to-destination, ending at the nearest qualifying spot within 1,500 m of the destination; the spot is returned in parking. If none is found, or the destination borough does not mandate bays for "ebike", the option stays direct with parking: null. Use destination_parking to tell “park anywhere” from “no parking found”. Ignored when a custom route is attached. Other option types are unaffected.
string
Rental e-bike operator (London): "lime" or "forest". Restricts the "ebike" bay search to boroughs the operator serves; when the destination borough isn’t served, the route ends at the nearest bay inside the operator’s area and walks the rest (destination_parking.covered: false).

Response body

Returns an envelope { search_id, routes, destination_parking }.
string
Unique identifier (UUID) for this request. Include it in support enquiries.
object | null
The destination borough’s rental e-bike parking rule. Set only for parking_type: "ebike" requests whose destination falls inside a bounded area (a London borough); otherwise null.
  • ebike_parking_rule: "bay_mandatory" (hires must end in a designated bay) or "free_floating" (park anywhere; render as “park anywhere in area_name”, not an error).
  • With an operator in the request, also carries operator and covered, indicating whether that operator serves the borough.
array
Array of route alternative objects
The response example is captured from a real request. Long arrays in it are abridged with . Each leg’s inner route object carries the same turn-by-turn shape as a Directions response.

Variants

With SuperSafe routing and a custom route

JavaScript

Route types

Personal bike

  • Direct cycling route, always first in results
  • With parking_type set: cycle to the returned parking spot, then walk to the destination

Docked bike-share (GBFS/TFL)

  • Walk → cycle station-to-station → walk
  • Included only when suitable stations exist within 1.5 km

Docked e-bike

  • Same shape, from the nearest station with an e-bike available; cycling legs use the e-bike speed
  • Marked is_electric: true; name is "{system name} E-bike"

Dockless bike-share

  • Walk to the nearest available bike → cycle to destination, one option per provider
  • Included only when a bike exists within 1.5 km

Custom routes

When event_id resolves to a custom route:
  1. All cycling segments route to the custom route’s starting point
  2. A non-reroutable cycling step is appended for the custom route itself
  3. Custom route details are included in each option’s event field
  4. For docked bike-share, the final walking segment goes to the nearest station to the custom route’s endpoint

Step semantics

Each leg’s route.routes[0].legs[0].steps follows the same turn-by-turn shape as the directions endpoint:
  • step.distance is the length of the road after the maneuver. To render “in X metres, …”, use the previous step’s distance.
  • step.maneuver.location equals step.geometry.coordinates[0].
  • The final step of the final leg is always "Arrive at destination".
  • voiceInstructions and bannerInstructions are generated per leg independently, because every leg ends in its own arrive step.

Error responses

400 Bad request

Out-of-coverage routing carries a machine-readable code and the request’s search_id:

401 Unauthorized

429 Too many requests

Includes a Retry-After header with the seconds until the current window closes:

500 Internal server error