restore_dashboard_version

Roll a dashboard's body back to a prior snapshot. Parameters, the reversibility guarantee and when it does not hold, errors and scope.

Replaces a dashboard's body with a prior snapshot's bytes. The slug, URL and metadata (name, tags, chart, visibility) are unchanged, and the new body is live immediately.

Use list_dashboard_versions first to choose a version_id. Do not guess one.

Behaviour hints for clients: not read-only, not destructive, idempotent, not open-world.

Parameters

Parameter	Type	Required	Notes
`slug`	string	yes	Canonical slug of the dashboard to restore.
`version_id`	string	yes	A UUID belonging to this dashboard, from `list_dashboard_versions`.
`workspace`	string	no	Workspace slug.

Returns

Restored revenue-overview to version 2c91....
URL: https://mickey.dashies.xyz/revenue-overview
The previous body was archived as version 5f77... first, so you can roll back to it with restore_dashboard_version.

That third line is the reversibility guarantee: the body you just replaced was snapshotted before the restore, and the id it names is how you undo. Read it, because it does not always hold. When the pre-restore snapshot did not land, the third line reads instead:

Note: a pre-restore snapshot of the previous body could not be saved, so this particular restore may not be undoable.

The restore still happened. What is missing is the way back.

On a workspace target the URL line reads URL: https://<workspace>.dashies.xyz/<slug>, and it is omitted entirely when the authorization carries no workspace slug to build it from.

Errors

The shared slug and version-id rules, plus:

Condition	Text
The version cannot be used	`version not found`
The version lookup failed	`version lookup failed: <err>`
The dashboard lookup failed	`dashboard lookup failed: <err>`
A workspace was named but not routed	`workspace target not resolved: this request names a workspace but was not routed to one (the caller must resolve the workspace and wire workspace-scoped deps)`

version not found covers four causes

Absent, belonging to someone else, belonging to a different dashboard, or stored under a non-canonical key all collapse into the same sentence. Distinguishing them would turn the refusal into an oracle for which version ids exist.

Ordering

The ordering is load-bearing and worth knowing when a restore fails partway: every authorization check runs before any write; the reversibility snapshot of the current body is taken before the destructive copy; and the database update is last. So a failure early leaves the live dashboard untouched, and a failure late leaves it restored.

Scope

Workspace-capable. Any current member may restore, which is the same set of people who can republish the body.

Check it worked

Load the dashboard URL and confirm it renders the older body. Then run list_dashboard_versions and confirm the version id the receipt named is present, which is what makes the restore undoable.