Data Lifecycle
Remem supports document lifecycle management plus tenant-level DSAR workflows.
Document lifecycle
1) Ingest
POST /v1/documents/ingest queues async processing and stores encrypted content + metadata.
2) Update (new version)
POST /v1/documents/{document_id}/update creates a new versioned document state.
3) Soft delete
DELETE /v1/documents/{document_id} marks the document deleted and queues cleanup.
Current behavior in code:
- vectors/files/cache invalidation is queued
- hard delete is scheduled with a grace delay
- default hard-delete grace window is 7 days
There is no public hard_delete=true flag on the document delete endpoint. Document hard delete is lifecycle-driven.
DSAR export (tenant scope)
GET /v1/dsar/export
curl -X GET "https://api.remem.io/v1/dsar/export?include_raw_files=true" \
-H "X-API-Key: vlt_..." \
-o remem-export.zip
Returns a ZIP stream with tenant metadata, documents, chunks, and optional raw files.
DSAR delete (tenant scope)
POST /v1/dsar/delete
curl -X POST https://api.remem.io/v1/dsar/delete \
-H "Content-Type: application/json" \
-H "X-API-Key: vlt_..." \
-d '{
"confirm": true,
"crypto_shred": true
}'
confirm=true is required.
Typical response fields include:
tenant_id
documents_deleted
chunks_deleted
entities_deleted
extracted_deleted
vectors_deleted
files_deleted
crypto_shredded
started_at
completed_at
Tenant deletion (management)
Tenant-level management endpoint:
DELETE /v1/tenants/{tenant_id} (soft)
DELETE /v1/tenants/{tenant_id}?hard_delete=true (hard)
These endpoints require a portal JWT and appropriate org/tenant role.
Crypto-shredding model
Remem uses tenant-scoped DEKs wrapped by a KEK.
With crypto_shred=true on DSAR delete, Remem destroys tenant key material so residual ciphertext becomes unrecoverable.
Retention notes
- Raw files may be retained with TTL rules and keep-forever policies.
- Queryable content lifecycle is managed via versioning + delete pipeline.
- Audit logs capture lifecycle actions for compliance and debugging.