Guides
Handle a deletion request
Create, verify, start, and complete a Rights deletion case.
Handle a deletion request
Source: app_docs/guide/rights.md, app_docs/api.md, app_docs/guide/faq.md.
Goal
A Rights case that moves through verification and execution with a visible timeline (Activity) and optional Evidence export.
Lifecycle
┌─ cancel ─────────────────────────────┐
│ ▼
OPEN ────┼── start ──► IN_PROGRESS ──► COMPLETED
(verify) │ │
│ └── fail ──► FAILED
│
└── (verification FAILED may remain OPEN)| Field | Values |
|---|---|
| Status | OPEN, IN_PROGRESS, COMPLETED, FAILED, CANCELLED |
| Verification | UNVERIFIED, VERIFIED, FAILED |
Start requires:
- Verification VERIFIED
- Start readiness — enabled Systems; each SQL system has ≥1 DELETE entity with identifiers
Prerequisites
- At least one enabled System
- SQL systems: Data Map with DELETE entities + identifiers
- Worker running (
bun run workerfor self-host; cloud must run a worker process) - Operational readiness not blocked
Without a worker, jobs stay PENDING.
Execution path
Start request
→ enqueue Job (rights.delete)
→ Worker claims job
→ Fulfill each enabled System using Data Map plans (SQL) or connector config (HTTP/Webhook)
→ COMPLETED or FAILED
→ Evidence assembles from Activity events| Outcome | Meaning |
|---|---|
| Completed | Fulfilment path finished successfully (systems reported OK) |
| Failed | Permanent or exhausted failure—see timeline |
| Partial | Some systems OK, some failed—timeline and Evidence should show honestly |
| Retry | Retryable errors requeue Job with backoff (runAfter) |
SQL connectors do not invent tables. Deletes use Data Map entities.
HTTP/Webhook run from connector config without a map.
Operator path
Workflow
- Open Operations (
#/rights). - Create a case: subject needs email and/or externalId (API:
POST …/cases). - Ensure verification is VERIFIED (operator verification is trust-the-operator—not OTP proof).
- Confirm start readiness.
- Start the case → job enqueued.
- Watch status: IN_PROGRESS → COMPLETED or FAILED.
- Inspect Activity timeline for system-level outcomes.
- Open Evidence when needed (
#/rights/:caseId/evidence).
Evidence payloads can show verifiedVia: otp for intake cases.
Public intake path
POST …/intake → email OTP → POST …/verify → request created VERIFIED- Case is not created until OTP succeeds.
- OTP stored hashed; single-use; attempt lockout; rate limited.
- Production: email via Resend (
RESEND_API_KEY); never return OTP in JSON. demoOtponly when not production orRIGHTS_INTAKE_DEMO_OTP=true.
Public routes:
GET /api/rights/v1/orgs/:orgSlugPOST /api/rights/v1/orgs/:orgSlug/intakePOST /api/rights/v1/orgs/:orgSlug/verify
Failure modes
| Symptom | Check |
|---|---|
| Cannot start | Verification, readiness, maps |
| Stuck pending / IN_PROGRESS | Worker process, same DATABASE_URL as app |
| Failed case | Timeline + connector health |
| No rows deleted | SKIP action, identifier mismatch, wrong table, preview COUNT was 0 |
FAQ notes
- Direct SQL from the browser is intentionally not how deletion works—cases + worker + maps give verification, retries, timelines, and Evidence.
- You can use Rights without Consent; you still need Systems (and Data Maps for SQL).