API Reference
Didit Console
Start typing to search…

Data Retention

How Didit stores, processes, and deletes verification data — and how you control it end-to-end.

Role & Processing Location

  • Processor role
    Didit acts as a data processor of your verification data; you are the controller.

  • Processing region
    By default, we process and store data in the EU. For enterprise accounts, we can enable in-country processing (local data residency) subject to availability and contract.

  • Regulatory posture
    Didit is designed to support GDPR and local data-protection regimes. Configure retention to meet your obligations (see below).

Need a DPA, TOMs, or other attestations? Contact your Didit representative.

🔧 Retention Controls (Console)

Configure retention in Business Console → App Settings → Data:

  • Default: unlimited (no time-bound policy until you set one)

  • Custom window: 1 month → 10 years

  • Scope: verification inputs/outputs, derived results, and operational/audit metadata kept by Didit

How to set it

  1. Go to Business Console → App Settings → Data

  2. Choose Retention policy (e.g., 1 month, 10 years, unlimited, etc.)

  3. Save

🗑️ Manual Deletion (Console)

From Dashboard → Verifications:

  1. Search/filter the target session

  2. Click Delete (top-right red button) → confirm

This is ideal for one-off removals or operational triage.

🔌 Programmatic Deletion (API)

Delete a verification session via API any time:

cURL

curl --request DELETE \
     --url https://verification.didit.me/v1/session/sessionId/delete/ \
     --header 'accept: application/json'

Expected responses

  • 204 No Content --- deleted

  • 404 Not Found --- already deleted or unknown session_id

⚡ Process-and-Purge Pattern (Webhooks)

Some customers let Didit process the data, then immediately purge it after receiving results through webhooks:

  1. Your backend creates a session

  2. Didit runs checks (ID, liveness, AML, etc.)

  3. Didit sends a webhook with status, identifiers (session_id, vendor_data), and verification data.

  4. Your backend persists only what you need (e.g., status, vendor_data)

  5. Your backend calls the DELETE session API for that session_id to remove data from Didit

🛡️ Security & Assurance

  • ISO/IEC 27001 ISMS in place (certificate/excerpts available on request)

  • Periodic penetration testing with tracked remediation

  • No known security breaches to date

  • Dedicated internal cybersecurity team; least-privilege access; strict env separation.

All API activity is recorded in Audit Logs, aiding security, compliance, and troubleshooting. Logs are retained 1 year (365 days) and then auto-deleted.

🔐 Privacy-Minimized Storage

We're adding features to let you retain only selected processing data --- for example, keep status and an identifier (vendor_data) while auto-purging heavier artifacts. This gives stricter control for teams operating under minimization principles.

Want early access or artifact-level retention rules? Contact us.

📚 FAQ

Can I set different retention per environment?
Yes --- you can setup different retention for each application you have in Didit.

Can I export before deletion?
Yes --- export via Console/API, then run the DELETE call.

Where can I see who accessed what?
Use Audit Logs --- filter by user, endpoint, date range; logs retained for 365 days.

🔏 Implementation Checklist

  • Configure retention in Console → App Settings → Data

  • Subscribe to webhooks; verify signatures

  • Persist minimal fields needed for your records

  • Implement DELETE endpoint if needed

  • Confirm processing region (EU vs in-country)

  • Separate Sandbox/Live keys & policies; rotate keys regularly