Delete Child Document
Delete a document. Storage, the timeline card, embeddings and extracted notes follow the row.
Storage cleanup, the L4 timeline_entries projection and the child_notes extracted from the document are DB triggers on documents; embeddings and ingestion_jobs are FK CASCADE; chat_messages / email_attachments references are FK SET NULL. Migration 20261007060803 lists what the delete does and does not reach. The timeline cleanup used to live here instead, and this was one of three handlers that delete a documents row - the other two never got it, including the deleteDocumentsBatch mutation every client actually calls, which is how a deleted record kept an undeletable card on the child's timeline. trigger_cleanup_document_timeline_entry (20260831072639) owns it now, in the same transaction as the row.
Idempotent: a delete for a row that's already gone (or never visible to this caller via RLS) returns 200 with deleted: False plus already_deleted: True when the caller is a family member. The client's stated intent - "this should not exist" - is satisfied either way. This protects callers whose previous attempt timed out server-side but actually committed (the prod 2026-05-27 case for document 1e23ffad-bbe3-43b3-b2c0-f7bc3fe6b939). A document_id that is not a syntactic uuid reaches that same answer rather than a 500 - it addresses no row by construction (#8840).
Authentication: JWT required Authorization: RLS - family members of the child can delete (see Family members can delete documents policy, migration 20251212110001_family_unit_invites.sql). On the idempotent retry path the user-client DELETE matched nothing and so proves nothing about the caller, hence the explicit family check before answering anything other than "not found".
Body: document_id: UUID of the document to delete
Response: {"success": True, "deleted": True} when the document row was deleted, or {"success": True, "deleted": False, "already_deleted": True} on the idempotent retry path. Existing clients only check success; the extra markers are purely informational for debugging.
Request
- Base URLhttps://api.projectindi.com (the document declares no server; this is the origin it was published from)
- Authnone declared
Path parameters
Request body
Response
Successful Response
Changes
No recorded changes to this operation across all 2 revisions of this API.