> ## Documentation Index
> Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Throw away selected changes from the version log

> Rolls each affected page back to the state it held immediately before the earliest version selected on it. The version log is a per-page timeline, not a stack of independent patches, so "undo this one change and keep the later ones" is not a question the stored data can answer — which is why the response names every later entry that goes with the selection, in `discarded[].alsoDiscarded`. Selecting several versions on one page collapses to a single rollback. Entries that cannot be rolled back are reported in `skipped` with a reason rather than guessed at.



## OpenAPI

````yaml /api-reference/orchestrator.openapi.json post /history/discard
openapi: 3.0.3
info:
  title: Avocado Studio Orchestrator API
  description: >-
    HTTP API exposed by the orchestrator. The brain that runs editor sessions,
    calls the LLMs, and serves draft state to integrated sites.


    The route list is the one the standalone Fastify server registers
    (`apps/orchestrator/src`); the handlers behind most of them live in
    `packages/orchestrator-core/src/http`, so library mode —
    `createOrchestrator()` from `@avocadostudio-ai/site-sdk` — serves the same
    shapes from the same code. Where the two differ, the route says so.


    **Note**: most routes carry no Fastify response schema, so responses are
    described in prose rather than typed here. Request shapes are taken from the
    handler source. See [the API Reference index](/api-reference) for context.


    **Auth**: in the standalone server only the agent surface enforces the
    access gate — `/chat` and `/ops` remain open. `createOrchestrator()` gates
    every route instead. Under that gate `GET /auth/status`, `POST
    /auth/verify`, `GET /health` and `GET /generated-images/*` are public — the
    first two are how a caller obtains a credential, a probe that needs one is
    not a probe, and an image tag on the rendered page cannot send a header —
    while every other route wants the token as `x-access-token`, `Authorization:
    Bearer`, or `?accessToken=` on `EventSource`. A refusal is `401` with
    `{"error":"unauthorized"}`. On a `closed` mount — `NODE_ENV=production` with
    no credential configured and no `auth` hook — that body also carries
    `reason`, the sentence naming the variable that would open it; `error` keeps
    its exact value either way, because that is the field the editor matches on
    to re-prompt.
  version: 0.11.1
servers:
  - url: http://localhost:4200
    description: Local development orchestrator (default port)
security: []
tags:
  - name: Sites
    description: Site registration and listing
  - name: Chat
    description: AI chat / planning endpoints
  - name: Sites Agent
    description: Site onboarding agent (migrate / integrate / create)
  - name: Draft
    description: Draft content read endpoints called by integrated sites
  - name: Publish
    description: Publishing and content snapshot endpoints
  - name: History
    description: Undo / redo / version log
  - name: Auth
    description: Optional access password gate
  - name: Media
    description: Image upload and generation
  - name: Health
    description: Service health and readiness
  - name: Operations
    description: Applying typed content operations directly
  - name: Checks
    description: Site-health check runs and findings
  - name: Restore
    description: Publish snapshots and rolling a draft back to one
  - name: Sessions
    description: Session introspection and admin
  - name: Preview
    description: Preview utilities
  - name: Telemetry
    description: Chat pipeline traces and feedback
  - name: Agent
    description: Open-ended agent loops — gated, and off in production by default
  - name: Jira
    description: Jira as a second input channel
paths:
  /history/discard:
    post:
      tags:
        - History
      summary: Throw away selected changes from the version log
      description: >-
        Rolls each affected page back to the state it held immediately before
        the earliest version selected on it. The version log is a per-page
        timeline, not a stack of independent patches, so "undo this one change
        and keep the later ones" is not a question the stored data can answer —
        which is why the response names every later entry that goes with the
        selection, in `discarded[].alsoDiscarded`. Selecting several versions on
        one page collapses to a single rollback. Entries that cannot be rolled
        back are reported in `skipped` with a reason rather than guessed at.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                session:
                  type: string
                  description: >-
                    Editor session key. Scoped with `siteId` into the key the
                    state store uses.
                siteId:
                  type: string
                  description: >-
                    Site this session belongs to, when the orchestrator hosts
                    more than one.
                versions:
                  type: array
                  items:
                    type: number
                  minItems: 1
                  description: Version numbers from `GET /history/log`.
              required:
                - session
                - versions
      responses:
        '200':
          description: >-
            `{ status: "applied", previewVersion, discarded: [{ slug,
            fromVersion, toVersion, alsoDiscarded }], skipped: [{ version,
            reason }], navigateToSlug?, canUndo, canRedo }`.
        '400':
          description: >-
            `session` missing, `versions` empty, or nothing in the selection
            could be discarded (`skipped` says why).

````