**Source URL:** https://general.veevavault.dev/regulatory/direct-data-api/guides/understanding-delete-extracts

# Understanding Delete Extracts

Direct Data API is designed to populate and maintain persistent tables in an external system, such as a data warehouse or data lake, rather than mirror your Vault's internal record state. Each extract CSV file represents one of these tables, and Direct Data API uses a corresponding `_deletes.csv` file to tell your integration when a row should be removed from that table. If a user deletes object records or document versions in Vault, Direct Data API stores it in a separate file by appending `_deletes.csv` to the extract name.

A row appearing in a delete extract means that row should no longer exist in your replicated table. It does not necessarily mean the underlying data was deleted from Vault. In some cases, the same information continues to exist in Vault under a different identifier or in a different extract, and your integration is expected to follow that change rather than treat it as a loss of data. For example,  and .

## Document Version Deletes

When a document is upversioned, Direct Data API removes the prior version's row from `document_version__sys.csv` and includes it in `document_version__sys_deletes.csv`. From a user's perspective, the document has not been deleted. It still exists in Vault, now represented by a new version ID that reflects the updated major or minor version number.

Treat this delete as an instruction to remove the stale version row from your target table, not as a signal to discard any information related to the document. If your integration needs to preserve a full version history, we recommend retaining the deleted version data in a separate historical table rather than removing it from your system entirely.

## Legacy Workflow Deletes

When a legacy workflow is completed or cancelled, Direct Data API removes it from the active legacy workflow extracts and includes it in the corresponding delete file. Learn more about these extracts in [Legacy Workflow Extracts](/direct-data-api/references/extract-naming/#Legacy_Workflow_Extracts).

The workflow has not been removed from Vault. It becomes available in the inactive legacy workflow extracts instead. As with document version deletes, treat this as an instruction to move the workflow from your active table to your inactive table, not as a signal to discard its data.

## Best Practices for Processing Deletes

When your integration encounters a row in a delete extract, confirm whether the related data is still available elsewhere in the Direct Data file before removing it from your target system entirely. Design your target system tables to mirror the structure of Direct Data API's extracts, so that a delete in one extract naturally corresponds to a record becoming available in another, such as moving from an active to an inactive legacy workflow table.

If your integration requires a complete history of changes beyond what the replicated tables provide, maintain this separately using the [audit log extracts](/direct-data-api/references/extract-naming/#Log_Extracts), which capture a record of changes independent of the replicated object, document, and workflow tables.

---

**Previous:** [Building Direct Data API Integrations](/regulatory/direct-data-api/guides/building-integrations)  
**Next:** [References](/regulatory/direct-data-api/references)