Consistency history and deletion

Plan for stored history and deletion routes that are not yet available in Preview.

The history and deletion routes are planned for stored Consistency records. They are not available in Preview because Preview keeps no document history between packets.

flowchart LR
  A["Packet in<br/>documents and known facts"] --> B["Compare<br/>documents and facts"] --> C["Plain answer<br/>what may disagree"] --> D["Proof<br/>where to check"]

History status

The current playground uses history off and compares documents within one packet. Stored API history is not available in this Preview configuration. A problem found in a packet remains in its packet response; deletion does not change a result already downloaded.

For claims reviewers

Preview has no stored document history. A Preview packet cannot match a document from an earlier packet, and there is no stored history to delete through these routes. A gateway without the history store returns 404 for them.

The planned routes will delete a stored document by its reference or delete stored documents by subject or file hash. A receipt will report what the store removed. It cannot remove a copy someone already downloaded.

Technical details

Authentication

Every route takes the same bearer key as POST /v1/consistency/packets:

Authorization: Bearer $MIGHTY_API_KEY

A key deletes only inside the labels its deletion grant covers. The labels come from the key's grant, never from the request. An org-wide deletion (all_labels: true) needs the admin deletion grant.

Delete One Document

DELETE /v1/consistency/documents/{document_ref}?client_ref=claims-east
Authorization: Bearer $MIGHTY_API_KEY

Part	Required	Rules
`document_ref` path parameter	Yes	The `documents[].document_ref` a packet response returned for the stored document.
`client_ref` query parameter	No	The `client_ref` label the packet was sent under. Omitted means your organization's default label.

Delete By Subject Or File

POST /v1/consistency/deletions
Authorization: Bearer $MIGHTY_API_KEY
Content-Type: application/json

The body is decoded strictly: an unknown field returns 400 invalid_json. Name exactly one selector.

Field	Type	Rules
`subject_ref`	string	Deletes every stored document of this subject. Use the same opaque ref your packets sent.
`document_sha256`	string	Deletes the stored document whose file bytes have this SHA-256, as 64 hex digits.
`client_ref`	string	Optional label to delete under. Omitted means your organization's default label.
`all_labels`	boolean	Optional. `true` deletes across every label of your organization and needs the admin deletion grant.

To delete one document by its document_ref, use the DELETE route above.

Deletion requests take no Idempotency-Key. If a request is interrupted, poll the deletion_id it returned instead of sending it again.

Response

A deletion that finishes inside the request returns 200:

{
  "deletion_id": "7c1a2f40-5b9e-4d8e-8a61-2f3e9c0d4b11",
  "state": "completed",
  "parts": ["7c1a2f40-5b9e-4d8e-8a61-2f3e9c0d4b11"],
  "documents_removed": 3,
  "rows_removed": 412,
  "backups_expire_at": "2026-10-25T00:00:00Z",
  "note": "downloaded exports are outside our control"
}

Field	Meaning
`deletion_id`	The deletion. Also the first entry of `parts`.
`state`	`completed`, or `running` when the deletion was interrupted and resumes on its own.
`parts`	The deletion's jobs: one, or several for an org-wide deletion over many labels.
`documents_removed`, `rows_removed`	What was removed from the live store.
`backups_expire_at`	When the last backup that still holds the removed data expires. Present when `state` is `completed`.
`note`	Data you downloaded before the deletion is outside the store and is not removed.

An interrupted deletion returns 202 with deletion_id, state: "running", parts, and status_url. Poll it:

GET /v1/consistency/deletions/{deletion_id}
Authorization: Bearer $MIGHTY_API_KEY

The answer has the same fields. A key sees a deletion only when its grant covers that deletion's label, and an org-wide deletion only with the admin deletion grant. Any other deletion returns 404 deletion_not_found.

Errors

Error bodies are {"error": "<message>", "code": "<code>"}. 503 carries Retry-After: 5.

Status	`code`	When
`400`	`invalid_json`	The body does not decode, or it has an unknown field.
`400`	`one_selector`	The request names no selector or more than one.
`400`	`invalid_document_sha256`	`document_sha256` is not 64 hex digits.
`401`	`api_key_required`	No valid API key.
`402`	none	Not returned by these routes. Deletion is never billed.
`403`	`deletion_not_granted`	The key's grant does not allow a deletion there.
`404`	none	The history store is not on for this gateway. The routes do not exist.
`404`	`deletion_not_found`	No such deletion, or your key's grant does not cover it.
`413`	none	Not returned by these routes.
`503`	`deletion_failed`	The deletion was not recorded. Send it again.
`503`	`store_unavailable`, `org_keys_unavailable`	The store or your organization's keys are not reachable. Retry after the delay.

Billing

Deletion and deletion receipts cost 0 SCU. Only packets are billed: consistency costs 6 SCU per page (an image document counts as one page). See Consistency Privacy And Billing.

Example Request

# Delete everything stored for one subject.
curl -X POST https://gateway.trymighty.ai/v1/consistency/deletions \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"subject_ref": "subj-y"}'

# Read the receipt.
curl https://gateway.trymighty.ai/v1/consistency/deletions/7c1a2f40-5b9e-4d8e-8a61-2f3e9c0d4b11 \
  -H "Authorization: Bearer $MIGHTY_API_KEY"

Next step

How the store keeps data

The privacy page explains keyed tokens, organization isolation, and retention.

See it on your files Open privacy and billing