> ## Documentation Index
> Fetch the complete documentation index at: https://docs.proofage.net/llms.txt
> Use this file to discover all available pages before exploring further.

# November 2026

> November 2026 changes to ProofAge: erase personal data through the API, the selfie.liveness.not_completed reason, MAX_ATTEMPTS_REACHED, webhook resend rules.

**November 10**

Decisions

* **New reason `selfie.liveness.not_completed`: a head movement not completed asks for a retake instead of declining.** Where ProofAge's head-movement check decides a facial age estimation, a person who did not complete the movement in any of the three tries, with no sign of a presentation attack in any of them, was declined with `selfie.liveness.failed`. The verification now ends `resubmission_requested` with `selfie.liveness.not_completed`, and the widget explains how to make the movement. A try with signs of a presentation attack still declines, and the attempt limit still applies. If your integration treats every `resubmission_requested` the same way, nothing changes for you. See [Liveness](https://docs.proofage.net/core-technology/liveness.md#when-the-head-movement-cannot-be-completed).
* **A try where the camera never started sending no longer counts** toward the three tries of the head-movement check, for example when the person had not yet allowed the camera.

**November 6**

API

* **Erase a verification's personal data through the API.** `DELETE /v1/verifications/{id}/personal-data` runs the same erasure as **Erase Personal Data** in the console and the MCP tools: images, recordings, document fields, analysis results and device data go; the status, reason, dates, audit trail and the fact of the erasure stay. Send `reason_code` (`data_subject_request`, `customer_request`, `retention_policy`, `test_data` or `other`) and, with `other`, a `reason`. Only `approved`, `declined`, `abandoned` and `expired` verifications can be erased; any other status answers `422 VERIFICATION_NOT_FINAL`. The answer is the verification with its `erasure` field set, and a repeat call answers the same way. Right after a decision it can answer `409 VERIFICATION_PROCESSING` with `Retry-After`. An erasure made this way reads `requested_via: customer`. See [Data retention and erasure](https://docs.proofage.net/console/data-retention.md#through-the-api) and [Error handling](https://docs.proofage.net/integration/error-handling.md#erasing-personal-data).
* **An erasure now deletes the capture recordings at once**, from the console and the MCP server too. Before, they stayed until their 30-day retention ran out.
* SDK releases to match: `@proofage/node` 0.15.0 (`erasePersonalData()`), `proofage` (Python) 0.10.0 (`erase_personal_data()`), `proofage/php-sdk` 0.10.0 (`erasePersonalData()`) and `proofage/laravel-client` 0.12.0.

**November 4**

Decisions

* **The document step of a facial age estimation now checks for screens and tampering.** When a selfie could not confirm the age and the person showed a document, the checks for a document photographed from a screen or altered were not applied, unlike every other document check. They are now, with the same reasons as on other workspaces, such as `document.front.spoof.screen_suspected` and `document.back.tampering.suspected`, and the same single retake when the screen is uncertain. In ProofAge's records no approved verification would have been decided differently. See [Facial age estimation](https://docs.proofage.net/core-technology/age-estimation.md).
* **A failure of ProofAge's head-movement check no longer declines.** If the check fails on ProofAge's side after the person finished it (for example, it runs out of time), the verification ends `resubmission_requested` with `verification.processing.failed` instead of `declined` with `selfie.liveness.failed`. `selfie.liveness.failed` now always means the check finished and found no live person. No verification was affected so far. See [Liveness](https://docs.proofage.net/core-technology/liveness.md).

**November 4**

Webhooks and API

* **Only the latest webhook can be sent again by hand.** **Retry** and **Resend** in the console, and the MCP tools `retry-webhook-delivery` and `resend-webhook-delivery`, now accept only the latest delivery of a verification to an endpoint. An older delivery may carry a status the verification no longer has, such as `approved` after a reviewer declined it, and sending it again could undo the newer decision in your system. The MCP tools answer `SUPERSEDED` for an older delivery, and `list-webhook-deliveries` returns `can_resend` next to `can_retry`. Automatic retries are not affected, and in a test workspace `get-webhook-delivery-request` still returns any delivery for replay. See [Webhooks](https://docs.proofage.net/integration/webhooks.md#responding-and-retries).
* **`MAX_ATTEMPTS_REACHED` on a retake with no attempts left.** A retake after `resubmission_requested` that would start an attempt over the limit is now refused at upload with `422 MAX_ATTEMPTS_REACHED` instead of opening an attempt past the limit. A new selfie on a facial age estimation that moved to a document already answered this way. Create a new verification. See [Error handling](https://docs.proofage.net/integration/error-handling.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.