Points-of-interest (cameras, fuel, parking) along a saved route

Returns amenity/POI matches along a previously-computed route, addressed by its saved route_id. This is the lazy, on-demand companion to the inline features[] channel on /routing/route: it does not call the routing engine and does not count against routing quota — it spatial-joins the requested feature types against the route's stored geometry and returns them sorted by distance along the route.

Use it to fetch dense or optional layers a driver pulls up when they want them — DOT traffic cameras, fuel stations, parking — without paying that cost on every route call. cameras and fuel_stations are available only here, not on the inline include_features channel (both are dense national layers — a camera-dense corridor can match thousands of points, and fuel stations are mapped at every interchange; keeping them off the synchronous route path keeps that call fast). Where a feed publishes per-station prices (EU national fuel feeds), they ride through in the feature's properties. The result is cached per route + type set and is subject to the same refetch rate limit as GET /routing/route/saved/{id} (1 / 30 s per route, 60 / minute per customer).

Each returned feature carries distance_along_route_m (distance from the route origin to the nearest point on the route), detour_m (perpendicular off-route distance to the feature), and side (left / right of the direction of travel; omitted for features essentially on the line).

Auto-saved routes (is_persisted=false) expire 30 minutes after the original routing call; after that this endpoint returns route_expired.

Plan-gated by count, identically to include_features: each plan caps how many distinct feature types you may request at once (Free: none; the cap rises with tier; Enterprise: unlimited). Your cap is published as routing_max_feature_types on GET /customer/plans.