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. Pagination and sorting are query parameters (top-level keys in the SDK); filter goes in body.

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.

Processing status


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, group, or date.
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.
Deletes are permanent — no recovery.

Processing queue

There is no separate processing endpoint. List documents and read system.status on each item.

Next steps