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

# Edit a memory into a new version

> An explicit edit: unlike a `save` that happens to resemble an existing memory, this
always creates a new version, no dedup classifier involved. The target must be an
active belief; the edited version goes stale and stays visible in `history`.




## OpenAPI

````yaml /openapi.yaml post /memory/{id}/update
openapi: 3.1.0
info:
  title: memloom local API
  version: 0.1.0
  description: >
    The HTTP API served by the `memloom serve` daemon on your machine. The CLI,
    the MCP server,

    and the viewer all route through this API. The daemon is the single owner of
    the store, so

    every client shares one consistent view of your memories.


    No authentication: the daemon binds to `127.0.0.1` only and is reachable
    solely from your

    own machine. Browser clients on other localhost ports are allowed via CORS.
servers:
  - url: http://127.0.0.1:4319
    description: Local memloom daemon
security: []
paths:
  /memory/{id}/update:
    post:
      summary: Edit a memory into a new version
      description: >
        An explicit edit: unlike a `save` that happens to resemble an existing
        memory, this

        always creates a new version, no dedup classifier involved. The target
        must be an

        active belief; the edited version goes stale and stays visible in
        `history`.
      operationId: updateMemory
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
          description: Any version's id in the belief's lineage works.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - content
              properties:
                content:
                  type: string
                  example: the staging database runs on Postgres 18
                canonical:
                  type: string
                  description: >-
                    Optional short canonical form used for exact-duplicate
                    detection.
      responses:
        '200':
          description: The new version.
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: string
                    description: >-
                      Id of the new current version (a fresh row; the edited one
                      is now stale).
                  rootId:
                    type: string
                    description: The belief's stable lineage id, unchanged across versions.
                  version:
                    type: integer
                    example: 2
        '400':
          $ref: '#/components/responses/ValidationError'
components:
  responses:
    ValidationError:
      description: The request body failed validation. `issues` names each offending field.
      content:
        application/json:
          schema:
            type: object
            properties:
              error:
                type: string
                example: invalid request body
              issues:
                type: array
                items:
                  type: object
                  properties:
                    path:
                      type: string
                      example: query
                    message:
                      type: string
                      example: query must be a non-empty string

````