Retención de comprobantes y datos

Una validación por imagen o PDF deja tres cosas distintas, y cada una tiene su propia regla de conservación:

qué	dónde vive	cuánto se conserva
El archivo del comprobante	Almacenamiento de archivos	Cinco años desde que se subió, salvo que se pida otra cosa con `retain_image` o con el borrado definitivo
El CEP	El XML en la base de datos y el PDF en archivos	Mientras exista la validación
Los datos extraídos y el resultado de Banxico	Base de datos	Mientras exista la validación

Retirar una validación con DELETE /v1/validations/{id} no cambia nada de esto: solo la quita del historial. Hay dos operaciones que sí cambian lo que se conserva, y cada una responde a una necesidad distinta.

No conservar el archivo: `retain_image`

retain_image es un parámetro opcional de POST /v1/validate-ocr, true por defecto. Con false, el archivo se borra en cuanto la validación llega a un estado terminal del que ya no se necesita. Vale igual con ?async=1.

Lo que se conserva es todo lo demás: el veredicto, el CEP y los datos extraídos. Lo que cambia:

La validación publica image_retained=false y deja de publicar image_path.
GET /v1/validations/{id}/image responde 410 image_not_retained, un código propio en lugar de un 404 genérico.

El archivo existe mientras la validación se procesa, porque el trabajo en segundo plano lo lee. El borrado espera solo en un caso: un CEP en PDF con un ciclo de reintentos abierto, porque cada reintento vuelve a comparar el sello del PDF contra el CEP oficial. Cuando ese ciclo cierra, por resuelto, agotado o cancelado, el archivo se borra. Una imagen no espera a nada. Una revisión posterior de un valid no lee el archivo.

Si activas los reintentos después de que el archivo ya se borró, el reintento sigue consultando a Banxico con los datos guardados y omite la comparación del sello (banxico_result._cep_upload).

Borrar una validación de forma definitiva

El borrado definitivo es lo que DELETE /v1/validations/{id} no hace: elimina el contenido, no solo la entrada del historial. Va en dos pasos, con el mismo patrón de preparar y ejecutar con un token de confirmación que usan las operaciones destructivas de administración:

POST /v1/validations/{id}/purge/prepare dice qué se borraría y qué se conservaría, avisa de que es irreversible y emite un token de un solo uso, atado a la cuenta y a esa validación, con vida de 120 segundos. No cambia nada.
POST /v1/validations/{id}/purge/execute verifica el token y borra.

Se admiten las validaciones propias en un estado terminal, incluidas las que ya retiraste del historial. Una validación en curso responde 409 purge_validation_in_progress; una ya purgada, 410 validation_purged; una ajena, 404 not_found. Un ciclo de reintentos abierto no lo impide: el borrado lo cancela.

Se borra:

El archivo del comprobante y el CEP, en XML y en PDF.
request_data, ocr_result, banxico_result y las advertencias de normalización. De normalized_data solo se conserva el monto.
Los registros derivados con datos personales: intentos de reintento, sondeos de cuenta, respuestas guardadas de Idempotency-Key, notificaciones de la bandeja y el contenido de las notificaciones enviadas.
El cuerpo enviado y la respuesta del receptor en las entregas de webhook de esa validación. El registro de cada entrega se conserva.
Los cuerpos de las filas de auditoría que nombran la validación y el contexto libre de sus eventos de seguridad, que se reduce a ids y códigos.
client_ref, porque es un texto libre que puede llevar datos personales.

Qué queda: la lápida

La validación no desaparece: queda como una lápida con lo estrictamente necesario para que la cuota, las estadísticas, finanzas y el historial sigan cuadrando.

se conserva	se borra
`id`, `validation_type`, `status`, `banxico_status`	El archivo, el CEP y `banxico_result`
`created_at`, `completed_at`, `deleted_at`, `purged_at`	`request_data` y `ocr_result`
`processing_time_ms` y `error_code`	`client_ref` y `normalization_warnings`
El monto, en `normalized_data.monto`	El resto de `normalized_data`

GET /v1/validations/{id} responde la lápida con 200 y purged_at. La imagen, el CEP, los reintentos y la revisión posterior responden 410 validation_purged, y los webhooks, los reintentos y los barridos la ignoran.

El borrado no devuelve cuota ni cambia lo cobrado, y los totales de finanzas y las estadísticas de la lista no cambian. Lo que sí desaparece de un reporte es el desglose que depende de los datos borrados: la validación ya no cuenta por beneficiario, por banco ni por contraparte, y el estado de cuenta la muestra sin clave de rastreo ni cuentas.

Lo que el borrado no alcanza

El borrado es irreversible y cubre lo que la plataforma guarda de esa validación, pero hay cosas fuera de su alcance:

Los respaldos de infraestructura no se alteran. Conservan una copia hasta que su ciclo de respaldos la retira.
El catálogo global de cuentas no guarda vínculo con la validación: una cuenta que un CEP confirmó entró a él por su cuenta y número, no por la validación, y el borrado no la toca. Lo que tu cuenta aportó al catálogo se retira cuando se da de baja tu cuenta.
Los archivos de registro del servidor se rotan por separado y no se redactan.
Lo que ya salió no se recupera: los webhooks que tu endpoint recibió, los mensajes de Telegram y lo que se envió a un tercero para leer el comprobante.
Otras validaciones con el mismo comprobante no se tocan. Cada una guarda su propia copia de lo extraído y se borra por separado. purge/prepare lista sus identificadores en same_image_validation_ids.
Las filas de auditoría anteriores a la versión 1.61.0 no mencionan la validación que crearon y no se pueden vincular a ella.
Los archivos que no se pudieron borrar al momento: el borrado responde file_removal: pending, la lápida conserva su ruta sin servirla y el barrido diario de comprobantes los termina.

Cómo hacerlo, paso a paso: Borrar una validación de forma definitiva.