Skip to main content
Deletion certificates are available to organizations with zero data retention only. Any other organization gets 403 with error_code: ZERO_DATA_RETENTION_REQUIRED from both calls below.
When a deleted document packet is purged, the platform issues it one deletion certificate: which workflow and packet it was, every file with its name and creation date, when the delete was requested and when the packet’s records were forgotten. A certificate is kept after its workflow is deleted, so you can still read it once nothing else of the workflow is left.

​
Status and assurance

A certificate is pending while a stored object of the packet is still queued for deletion, then final. A final certificate carries an assurance:

​
Verifying a certificate

A final certificate is signed shortly after it becomes final. Until then document_base64, signature_base64, document_sha256 and signing_key_id are null. Once signed, document_base64 is the XML document exactly as signed, and signature_base64 is a detached ECDSA P-256 signature over its SHA-256, DER-encoded. Decode both and check them with the public half of the key signing_key_id names: