Route briefing: one API call for a whole task
A multi-point route is not the same as one straight corridor. The new route briefing workflow accepts task points, samples each leg, and returns forecast values with route metadata.
The corridor endpoint is still the right primitive for a straight line: launch point, bearing, distance, spacing. That shape is simple, fast, and useful when an app wants to look ahead along the next leg. But a task planner usually has something richer in hand. It has named points, turnpoints, legs, cumulative distance, and a pilot speed assumption. Treating that as one bearing is wrong.
So there is now a workflow endpoint for the higher-level job: `POST /v1/workflows/route-briefing`. Send a list of route points, choose `sample_mode=legs` for regular samples along each leg or `sample_mode=waypoints` for just the supplied points, and optionally turn on `time_aware` with a launch time and ground speed. The response comes back with route distance, leg metadata, ordered samples, estimated arrival times, and a small summary of the weakest bits of the route.
The important detail is that this is still real model data. The workflow does not read colours from a map image or invent a route score from a screenshot. It resolves each waypoint or generated leg sample to the forecast grid, reads the same WRF-derived fields used by `/v1/site` and `/v1/corridor`, and returns values such as `wstar_ms`, `cloudbase_agl_ft`, wind, convergence, terrain height, and `day_rating`.
That makes the public route demo honest. The map is still an archived preview, but the request shape shown beside it is now a real API contract rather than a sketch of what the site needed. The example is also in the API examples, and the app-building guide now points route workflows at this endpoint instead of pretending corridor accepts arbitrary waypoints.
For developers, the split is cleaner. Use `/v1/corridor` for one straight line. Use `/v1/workflows/route-briefing` for a task, club briefing, instrument route context, or anything with named points. The developer page lists both, and the instrument-maker page calls out the hardware use case. Full schema is in the OpenAPI reference.