Deleting documents, memories, and starting over

Documents and memories are separate layers

Supermemory stores what you send as a document, keeps chunks of it for retrieval, and derives memories — extracted facts — from it. Deletion works differently at each layer, so start by deciding what you actually want gone:

• A source item you ingested — delete the document.
• A specific fact Supermemory learned — forget the memory.
• Everything belonging to one user or tenant — delete the container tag.
• Everything in the organization — reset the organization.

Deletes are permanent, with no recovery.

Deleting one document

Call DELETE /v3/documents/{id}. The path accepts either the document ID Supermemory assigned or your own customId, so you can delete by your identifier without looking anything up first. A successful delete returns 204 with no body.

await client.documents.delete("doc_abc123");

You can do the same for an individual item from the Supermemory dashboard, using the delete action on the document. If you cannot find the control for a particular item, use the API call above or ask support.

Deleting many documents at once

Call DELETE /v3/documents/bulk with a list of document IDs. A maximum of 100 IDs is accepted per request, so larger cleanups need to be chunked into batches of 100.

await client.documents.deleteBulk({
  ids: ["doc_1", "doc_2", "doc_3"]
});

The response includes deletedCount and a per-ID errors array, so check it rather than assuming every ID in the batch succeeded. Note that this endpoint uses the DELETE method with a request body — some HTTP clients drop bodies on DELETE, which is a common cause of unexpected 400 responses.

Deleting everything for one user

Do not enumerate a user's documents to delete them one by one. Call DELETE /v3/container-tags/{containerTag} instead. It removes the container tag together with all of its documents and memories, and returns counts of both. This is the cleanest way to honor a per-user deletion request.

The call requires organization owner or admin permissions, and it is permanent.

Forgetting a single memory

To remove one extracted fact rather than a source document, call DELETE /v4/memories with the containerTag and either the memory id or its exact content. You can pass an optional reason that is stored with the record.

This is a soft delete: the memory is marked as forgotten and stops being returned by search, but it is not purged from the database. Forgetting a memory that is already forgotten returns 409.

Forgetting memories by topic

Call POST /v4/memories/forget-matching to clear out everything matching a description — for example, all memories about a former employer. Pass a containerTag plus either a natural-language query or a list of memory ids (up to 500).

Always run it with dryRun: true first. That returns the candidate matches and a summary without changing anything, so you can confirm the scope before committing. Useful controls:

• threshold — minimum similarity for a match, default 0.5. Raise it to be stricter.
• maxForget — cap on how many memories a single call removes, default 100, maximum 500.
• reason — stored with each forgotten memory for later auditing.

Like the single-memory endpoint, this is a soft delete.

Does deleting a document remove its memories?

Deleting a document removes that document. The documentation does not state that memories already derived from it are removed at the same time, so do not assume it when you need a guarantee. If your goal is that nothing derived from the content can be recalled, either delete the whole container tag — which explicitly removes documents and memories together — or follow the document delete with a forget-matching call scoped to that content. Support can confirm the exact behavior for your case.

Starting completely over

To wipe an organization and begin fresh, call POST /v3/settings/reset with a non-empty confirmation string in the body. It deletes documents and document batches, memories, spaces other than the default project, external service connections, and organization settings. It preserves the organization itself, its members, and billing information.

The response reports how much was removed in each category. This is irreversible — treat it as a last resort, and prefer per-tag deletion if only some tenants need clearing.

Documents that are still processing

Ingested content moves through queued, extracting, chunking, embedding, indexing, and then done or failed. You can see what is in flight with GET /v3/documents/processing.

There is no documented way to cancel a document that is already being processed. If you have ingested something by mistake, wait for it to reach done or failed, then delete it normally. If a large accidental ingest is still running and you need it stopped, contact support promptly rather than waiting it out.

Deleting chats in the consumer app

Chat history in the Supermemory consumer app is managed inside the app itself. Deleting a chat and deleting the memories saved from that chat are separate actions — clearing a conversation does not necessarily remove facts already extracted from it. To be certain a fact is gone, forget the memory directly using the endpoints above, or ask support to confirm what remains.

What deletion means for billing

Billing is usage-based and metered on work performed: tokens ingested, search queries, and platform operations. It is not a storage subscription. That has two consequences worth understanding:

• Deleting documents or memories does not refund usage you have already consumed. The ingestion was billed when it happened.
• Deleting content and re-adding it later costs full price again. If your goal is to refresh content rather than remove it, re-ingest under the same stable customId instead — updates under an existing customId bill only the net-new token difference, so unchanged material costs nothing to re-sync.

In short, delete to control what your application can recall, not to reduce your bill.

Contacting support

Contact support@supermemory.com if you need a bulk deletion beyond what the API covers, need to stop an ingest that is still running, or need confirmation that specific content is fully removed for a compliance request. Include your organization ID, the container tag involved, the document IDs or customIds in question, roughly how many items are affected, and whether the request is time-sensitive.