Getting Started
What Erasure is, how the privacy workflow fits together, and how to run your first real operations.
Getting Started
This is the canonical onboarding path for Erasure.
By the end of this section you should be able to:
- Explain what Erasure is (and is not)
- Create an organization and project
- Publish a consent experience and collect a receipt
- Connect a system and understand deletion readiness
- Run a deletion case and export evidence
If you only have half an hour, follow First 30 minutes.
Welcome to Erasure
Erasure is privacy operations infrastructure for product teams.
It helps you:
- Collect consent with durable proof (not only a banner)
- Map where personal data lives
- Fulfill deletion requests against real systems
- Export evidence of what happened
The primary buyers are founders, CTOs, and engineering leads who need runtime operations—not a document-only compliance suite.
What to do next
Open the product at app.erasurehq.in when you are ready to click through, or keep reading for the full mental model first.
What Erasure is
Erasure is a privacy engineering platform with one account and shared tenancy:
| Capability | What it does for you |
|---|---|
| Consent (Anumati) | Versioned notices, publishable config, SDK, append-only receipts |
| Systems | Connectors to places data lives: PostgreSQL, MySQL, HTTP API, Webhook |
| Data Maps | Tables, identifiers, and delete-vs-skip plans before execution |
| Rights / Operations | Deletion cases with verification, jobs, and honest outcomes |
| Evidence | Exportable packages for consent publish and deletion outcomes |
| Operational readiness | Signals whether you can safely start deletions |
Everything sits on one platform shell: users, organizations, projects, billing entitlements, and operator sessions.
Who it is for
| You are… | You use Erasure to… |
|---|---|
| Founder / CTO | Stand up consent + deletion without building it yourself |
| Engineer | Integrate the SDK, connect databases/APIs, run jobs |
| Ops / privacy owner | Track cases and export evidence for internal review |
What problems it solves
Without infrastructure, teams usually end up with:
| Need | Common failure mode |
|---|---|
| Prove what people agreed to | Banner with no receipt, no version history |
| Honour deletion requests | Email → manual SQL → no consistent trail |
| Know where PII lives | Tribal knowledge across services |
| Show what happened | Logs that nobody can hand to a reviewer |
Erasure replaces that with configured product surfaces and exportable packages.
The DPDP-shaped workflow
India’s DPDP framework is why many teams evaluate Erasure. In product terms, the loop looks like this:
Workflow · Privacy operations loop
- Collect — publish a notice and record choices as receipts
- Map — connect systems and define where subject data lives
- Fulfill — open a deletion case, verify, run jobs across systems
- Prove — export evidence of publish or deletion outcomes
Detailed DPDP-oriented documentation will live under DPDP (section expanding later). For now, treat the loop above as the operating model.
Create your first organization
- Go to Register (or Sign in if you already have an account).
- Create an organization — billing and Rights boundary.
- Create a project — the surface for consent, publishable keys, and receipts (for example “Marketing Site”).
You land on the project home. From there you configure Consent, open Develop for keys, and use Rights for systems and cases.
Roles (quick reference)
Operators belong to an organization with a role:
- Owner — full access including billing and key create/revoke
- Admin — read/write across product surfaces
- Viewer — read only
End users of your product are subjects, not console users.
What to do next
Full detail: Access & setup.
Publish your first consent experience
- Open Consent for your project.
- Add purposes (at least one required purpose).
- Edit notice copy (title, description, labels).
- Publish → a consent version is created.
- Open Develop → create a publishable key (
pk_live_…). Copy it once; you will not see the raw secret again.
In your application, initialize the browser SDK with that key and your Erasure origin (see Access for a minimal snippet).
Accept the banner in a browser, then confirm a row under Receipts.
Connect your first system
Deletion only works against systems you configure.
- Open Rights → Systems.
- Add a connector (start with PostgreSQL if that is where user data lives).
- Save credentials (stored encrypted).
- Run a health check.
- Open Data Map for that connector:
- Discover schema
- Map entities (tables) and subject identifiers
- Mark DELETE or SKIP
Supported connector types today: PostgreSQL, MySQL, HTTP API, Webhook.
Submit your first deletion request
- Confirm operational readiness is not blocked (systems healthy enough, maps ready for SQL, worker available).
- Create a Rights case:
- Operator path — create a request in Operations, verify the subject, then start
- Public intake — subject verifies email via OTP; request is created only after OTP succeeds
- Start the case when verification is VERIFIED and start readiness allows it.
- Watch status:
OPEN→IN_PROGRESS→COMPLETEDorFAILED.
Outcomes are honest: failures and partial system results show on the timeline—not a single green “magic delete.”
Generate evidence
When you need to show what happened:
- Open the case (or a consent publish surface that exposes Evidence).
- Open Evidence.
- Export JSON, CSV, or a human-readable report.
Evidence kinds in product today include consent publish and rights deletion packages. Packages are assembled on read from stored domain facts—not a separate sealed archive product.
Where to go next
| Goal | Go to |
|---|---|
| Thirty-minute path | First 30 minutes |
| Account, org, keys | Access & setup |
| DPDP-oriented framing | DPDP (expanding) |
| Product language | Core Concepts (expanding) |
| Task guides | Guides (expanding) |
| Diligence | Security · marketing Security page |
What to do next
Start the guided path: First 30 minutes.