Handling DSRs (GDPR)

Under GDPR (and CCPA, the Australian Privacy Act, and a growing number of state laws) end users have the right to access, rectify, port, restrict, object to processing of, and erase their personal data. This guide explains how VEREID handles those rights, how to delegate them when you are using VEREID as a processor, and how to plug your own systems into the flow so the user has a single experience.

Where each right is implemented

All endpoints require the user's own bearer token (issued via OIDC). They cannot be invoked with a tenant API key — that boundary is intentional.

Delegation for B2B tenants

If you onboard end users through VEREID Auth or ID, VEREID is the controller of identity data (the actual document, the biometric template) and you are the controller of your application data. When a user DSRs you, the typical responsibility split is:

1. You receive the request, verify the user's identity (re-authenticate them via VEREID Auth).
2. You hand them back the parts of their data that you control.
3. You redirect them to VEREID for the identity portions, or — better — you call the delegated DSR endpoint on their behalf and bundle the result.

curl -sS -X POST https://api.vereid.com/v1/developer/dsr/initiate \
  -H "Authorization: Bearer $VEREID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "user_sub": "u_01HZ...",
    "purpose": "access",
    "delegated_by_tenant": true
  }'

const job = await vereid.developer.dsr.initiate({
  userSub,
  purpose: "access",
  delegatedByTenant: true,
});

The user receives a confirmation email from VEREID asking them to authorise the delegated request. On authorisation, we process the request and ship the export bundle directly to a callback URL you specified.

The data we export

POST /v1/me/data-export produces a signed .zip containing:

• profile.json — display name, handle, public links, bio.
• posts.ndjson, comments.ndjson, likes.ndjson, follows.ndjson, messages.ndjson — every social artifact authored.
• verifications.ndjson — every verification session, with decisions and tiers (no raw biometric data).
• documents/<id>.<ext> — the original ID documents (still encrypted at rest with our KMS CMK; we wrap them in a separate envelope with a per-export DEK so leakage of the URL alone is not enough to read them).
• audit.ndjson — every entry from audit_events involving this user.
• oauth_grants.json — the apps you have signed into via VEREID.

Erasure semantics

Erasure is two-phase:

1. Soft delete (instant) — user is marked deleted; sessions invalidated; biometric template purged; document images flagged for deletion; tenant API key responses 404 the user.
2. Hard purge (within 30 days) — every row containing personal data is hard-deleted from primary stores and from backups by the next monthly backup rotation. Hashes in audit_events are retained (audit is exempt from erasure under Art. 17(3)(e)) but the user's email, phone, and display_name columns are nulled.

We emit user.deleted and user.purged events at each phase. Subscribe both if you mirror user records on your side.

Restriction

When restriction is invoked, VEREID stops processing the user's data for any purpose other than storage and the requested DSR fulfillment. Tenant API key reads return 409 user_restricted with a problem document so your downstream code can degrade gracefully.

Right to human review (Art. 22)

Automated verification decisions are subject to Art. 22. The hosted flow always advertises the user's right to request human review, and POST /v1/me/verifications/<id>/review enqueues that review into the admin console. The user receives a status update within 7 business days. Re-decision is honoured.

SLAs

• We acknowledge a DSR within 3 business days (auto via email).
• We complete a DSR within 30 days (GDPR-equivalent across all our jurisdictions).
• Where a DSR materially affects a tenant (e.g. erasure of a user with active verifications), the tenant is pre-notified via user.deletion.scheduled 7 days in advance.

Records

Every DSR is logged in consent_events and in our audit trail. Regulator requests are answered from those records; we do not rely on email threads or ad-hoc spreadsheets. The combined audit + consent log is sufficient to demonstrate Art. 30 compliance.

What you should build

• A self-service "Download my data" button in your app that calls our delegated endpoint.
• A "Delete my account" flow that confirms via re-authentication, calls POST /v1/me/delete, and waits for the user.purged event before showing the success state.
• A clearly-labelled rectification UI for the fields you control.

Each is one API call.