Skip to main content
POST
curl

Overview

Deletes one or more User entities. The user records are removed permanently. Their verification sessions are not covered by this endpoint and survive with their link to the user cleared; delete them with Delete Session or Batch Delete Sessions. Transactions are not covered either; delete those from the Console.

When to use it

  • Right-to-be-forgotten requests (GDPR / CCPA).
  • Clean-up of test users during QA.
  • Deprovisioning users removed from your own platform.

Notes

  • Accepts a list of vendor_data values, a list of didit_internal_id values, or delete_all: true. The two lists can be combined and are OR’d.
  • The Console’s filter_* batch params are rejected with a 400. This endpoint has no Users table to narrow, and silently ignoring them on delete_all would delete every user in the application.
  • All-or-nothing: if the deletion cannot be completed for the users you selected, none of them is deleted and you can safely repeat the same request.
  • Idempotent — re-sending the same list returns deleted: 0 after the first run.
  • Returns only a count of what was deleted, not a per-item report. Values that matched nothing are skipped silently. Send a de-duplicated list if you want to compare deleted against the number of identifiers you sent, since a repeated identifier is only counted once.
  • No webhook is emitted for a deletion. Webhooks fire on user status and data changes, not on delete — so an integration that needs a deletion signal must record it on its own side.
  • Verification sessions linked to the user are NOT deleted by this endpoint. They remain, with their link to the user cleared, so their documents, faces and media are only removed once you delete the sessions themselves.
  • Retained biometric templates anchored to the user ARE purged, before the user is deleted. If a template cannot be purged because a biometric store is unavailable, the call returns 503, no user in the request is deleted, and repeating the request finishes the job.

Permissions

Any active API key of the application can call this endpoint. Didit API keys are application-scoped, not role-scoped: the Console’s roles and permissions (delete:users and the rest) decide what a person can do in the Console, and are not evaluated for Management API traffic. Control who can call this endpoint by controlling who can read the application’s API key.

Authorizations

x-api-key
string
header
required

Your application's API key, from Developers -> API keys in the Business Console. The primary key has full access. A named key can be scoped: none, read or write per resource, limited to some workflows or to approved sessions, to a list of IP addresses, and to an expiry date. 401 means the key is missing, wrong, revoked or expired; 403 means the key has no access to this resource or action, or the request came from an address outside its IP list; 404 on a session route means the session is outside the key's workflows or statuses. A key without media access receives image, video and PDF URLs as null, and a key without sessions write receives session links and tokens as null. See https://docs.didit.me/console/api-keys.

Body

application/json

Provide vendor_data_list, didit_internal_id_list, or delete_all: true. The two lists can be combined and are OR'd. When delete_all is true it takes precedence and both lists are ignored.

vendor_data_list
string[]

Your own identifiers to delete, matched exactly as sent.

didit_internal_id_list
string<uuid>[]

Didit internal user IDs to delete - the didit_internal_id returned by the create and get endpoints.

delete_all
boolean
default:false

If true, deletes every user in the application.

Response

Users deleted. Returns the number of users actually deleted.

deleted
integer

Number of users deleted (excludes vendor_data values that didn't match anything).