Skip to main content
Manage documents after ingestion using the SDK. Every call is scoped to one namespace (what v3/v4 called a container tag).

List documents

Retrieve paginated documents with filtering. One list call serves documents, chunks, and memories; pick with type.
Response:
Every response contains documents, chunks, memories, and pagination. Only the array for the requested type is filled.

Parameters

namespace and type are required. Over HTTP, pagination and sorting are query parameters and filter and include go in the JSON body; the SDK takes them all in one options object after namespace and type. Unknown query or body keys return 400.

Include extracted content

Document lists omit content by default. To include the last published extracted text, including text from uploaded files, set include.content in the JSON body:
content is null until the first extraction publishes. When you replace a file, the previous text remains until the new extraction publishes. It also remains if the replacement fails. Including content can make pages large.

Get document

Get a specific document with its processing status. Pass include to include its chunks and memories.
The id may be the Supermemory document ID or the id you supplied at ingestion. It resolves only inside the namespace in the path.
The current HTTP response also includes system.dreamingStatus. TypeScript SDK 5.0.1 and Python SDK 5.0.0 do not expose that field in their generated models; Python’s system.dreaming_status is not available. Use the raw HTTP response when monitoring memory generation with these versions, or upgrade the TypeScript SDK to 5.0.2 for typed system.dreamingStatus. system.status: "done" alone does not mean memories are ready.

Processing status

Treat any status other than done or failed as still in progress.

Memory generation status

system.dreamingStatus tracks memory generation separately from system.status. With the default dreaming: "dynamic", Supermemory batches related documents before forming memories, so status can be done minutes before dreamingStatus is. If your next step reads memories or profiles, wait for dreamingStatus to be done too.

Update document

Update a document’s content or metadata. Content changes trigger full reprocessing; metadata-only changes (e.g. updating accepted, version) do not reindex. The body accepts any non-empty subset of content, metadata, supportingContext, or date. Metadata merges key by key. group is an ingestion-side setting: it picks which existing memories serve as context while content is processed, so changing it only takes effect when the document is re-ingested. Send it together with content.
For file-backed documents use documents.updateFile (PATCH: partial, file optional, metadata merges key by key) or documents.replaceWithFile (POST: full replace, file required, omitted metadata keys are cleared).

Delete documents

Permanently remove documents. One call deletes 1 to 100 documents by Supermemory or caller-defined ID.
Inspect both count and per-ID errors; HTTP success can include partial failures. Only documents whose system.status is done or failed can be deleted; a document that is still processing is reported in errors as Document is still processing. Memories derived from a deleted document are forgotten.
Deletes are permanent — no recovery.

Processing queue

There is no separate processing endpoint. List documents and read system.status and system.dreamingStatus on each item in the HTTP response. The SDK examples below count documents still being indexed; use raw HTTP for memory-generation status with the SDK versions noted above.

Next steps