DPDP for developers: what the Act actually requires from your auth layer

The Digital Personal Data Protection Act isn't a lawyer problem — it's an API surface problem. If your auth layer can't produce consent records and honor erasure requests, the compliance burden lands on your code.

What DPDP requires, mapped to APIs

Purpose-level consent — not "I agree to everything" but recorded consent per purpose with version + timestamp. When a user authenticates, the consent intent travels with the session.

Withdrawal — revoking consent must be as easy as giving it. That's a real endpoint, not an email to support.

Data Principal rights — access (export everything), correction, erasure, grievance. Each is an API + an audit trail.

Notice — before collection, tell the user what, why, and for how long.

The tamper-evidence detail everyone misses

Consent records that live in a mutable table are weak evidence. A hash-chained ledger — each row's hash commits to the previous — makes retroactive edits detectable. That's what auditors will ask for in 2027.

What NexAuth gives you out of the box

• Consent records bound to authentication events (purpose + version + timestamp)
• Withdrawal API with webhook propagation to your systems
• DSR export + erasure endpoints
• Hash-chained audit trail on every sensitive record
• Data minimization defaults: we store identifier + session, nothing else

Compliance stops being a scramble when it's a column in your auth schema.