v1
mcp

Rename a saved document and/or update its out-of-flow parts (headers, footers, footnotes, endnotes, comments, sections).

Rename one of your saved documents and/or update its out-of-flow parts. Parts are the document's out-of-flow content — headers/footers, footnote and endnote bodies, comments, and per-section page geometry. Every fragment is sanitized on write, writes are versioned and safe under concurrent editors, and parts revert with the document. A title-only call behaves exactly as the original rename (response status:"renamed"). Part content lives in the document body and is edited exactly like any other document content (via chat or the document write endpoints); a legacy parts payload returns 400 parts_moved_to_chunks pointing you there.

patch/v1/documents/{document_id}

Request

  • Base URL: https://api.superdocs.app
  • URL: https://api.superdocs.app/v1/documents/{document_id}
  • Auth: HTTP bearer

Path parameters

document_idstring required

Headers

authorizationstring nullable

Request body

titlestring nullable

New document title.

partsobject nullable

Document-parts patch — the document's OUT-OF-FLOW content, keyed by any of: sections, headers, footers, footnotes, endnotes, comments. Each key you send REPLACES that whole part family; a null value clears it; keys you omit are untouched. Every HTML fragment is sanitized server-side. Headers/footers are keyed by section index with default/first/even variants; dynamic page fields use <span data-field="PAGE|NUMPAGES|DATE">cached text</span>.

base_partsobject nullable

Optional concurrency guard: the parts subtree your edit was based on (as last read). If another writer changed one of the same part families since, your write still lands (newest-write-wins) and the overwritten families are reported in parts_conflicts. Send it whenever you can — it makes the report PRECISE. Omit it and the write is treated as unvouched: every family whose existing content your payload replaces or clears is reported in parts_conflicts, since without a base the server cannot tell an intended update from an accidental overwrite. Each family you send REPLACES that family whole, so sibling entries you omit (e.g. the first-page header variant) are deleted.

Response

Successful Response

unknown required

Changes

No recorded changes to this operation across all 1 revision of this API.