---
title: "Nl Plan Detail"
method: GET
path: "/api/v1/planner/history/{plan_id}"
tags: ["planner"]
---

# Nl Plan Detail

`GET /api/v1/planner/history/{plan_id}`

## Request

- Base URL: `https://yondry.app` (the document declares no server; this is the origin it was published from)
- URL: `https://yondry.app/api/v1/planner/history/{plan_id}`
- Auth: HTTP bearer

One stored plan, in full, so a past day can be opened again.

The app had no way to do this. The only action on a history entry was "Use
again", which re-runs the query and generates a *different* day — so the
plan itself, with its stops, times and coordinates, was written on every
query and never read back. Hundreds of stored days, none of them viewable.

Scoped to the caller: another user's plan is a 404, not a 403, so the
endpoint does not confirm that an id exists.

## Path parameters

- `plan_id` string, uuid, required

## Response `200`

Successful Response

- GeneratedPlanDetail: One stored plan, in full. Deliberately mirrors the shape of the query response, down to the `generated_plan_id` field name, so the app renders a past day with the renderer it already has rather than growing a second one that drifts from the first. `plans` is typed loosely on purpose. These rows go back to the app's first weeks and the plan shape has changed since; validating them against today's schema would turn an old day into a 500 rather than a slightly sparse page. The client already tolerates missing fields.
  - `generated_plan_id` string, uuid, required
  - `query` string, required
  - `plans` object[], required
  - `intent` object, required
  - `weather` string, nullable, required
  - `feedback` string, nullable, required
  - `saved` boolean, required
  - `generated_at` string, date-time, required

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/yondry/apis/yondry-api.md) · [All operations](https://skmtc.dev/yondry/apis/yondry-api/llms.txt) · [OpenAPI document](https://skmtc.dev/yondry/apis/yondry-api/revisions/d2c213cea95b?raw)