Standardized Erasure Interface for DPDP Consent Managers

Standardized erasure interfaces across all consent managers makes it easy to manage compliance on various enterprise systems.

This is a continuation of our series on operationalizing the DPDP Act from an IT systems standpoint. We previously introduced Compliance Enforcement Service for automating retention & erasure flows and a DPDP Wallet for the convenience of data principals to manage consent across data fiduciaries. In this post, we aim to highlight the importance of standardized erasure interfaces between the Consent Manager and various Data Processors.

In high-transaction entities such as hospitals, financial institutions, and retail outfits, manual compliance is not practical. A single hospital works with dozens of software vendors for billing, lab reports, and pharmacy. If the erasure interface is different for each consent manager, it results in significant custom integration effort.

To simplify this, we propose a standardized erasure interface that all consent managers can agree on. This enables plug-and-play for all enterprise systems to connect with any consent manager without changing the API specifications.

As a start, we are publishing the erasure interfaces that we are supporting as part of our open source consent management system. The following JSON structures show how a Data Processor (vendor) interacts with a Consent Manager to automate the data lifecycle.

1. Retrieving Pending Erasure Requests

The data processor can poll the Consent Manager to see which users have withdrawn consent or reached their statutory retention limit.

Request (POST /api/v1/processor/purge-queue):

{
  "_func": "list_purge_requests",
  "fiduciary_id": "HOSP_7721_CBE",
  "batch_limit": 50
}

Response:

{
  "total_pending": 1,
  "requests": [
    {
      "request_id": "PRG_8821_XYZ",
      "user_id": "patient_rahul_99",
      "data_category": "HEALTH_VITALS",
      "action_required": "HARD_PURGE",
      "deadline": "2026-03-01T10:00:00Z"
    }
  ]
}

Alternatively the Consent Manager can push this data to the data processor’ endpoint and receive the response from the data processor asynchronously.

2. Updating Erasure Fulfillment Status

Once the data processor has successfully deleted the data, they must “close the loop” by sending an immutable proof of fulfillment back to the consent manager.

Request (POST /api/v1/processor/purge-status):

{
  "_func": "update_purge_status",
  "request_id": "PRG_8821_XYZ",
  "status": "COMPLETED",
  "evidence_hash": "sha256_b4f9a1c2...",
  "completion_time": "2026-02-15T12:15:00Z",
  "details": "PII scrubbed from primary storage and backups."
}

Response:

{
  "success": true,
  "audit_log_id": "AUDIT_9912_LOG",
  "message": "Fulfillment recorded in the immutable compliance ledger."
}

By adopting standardized interfaces like these we shift the burden of DPDP compliance from administrative staff to the technology itself. This protects the Data Principal while saving time and costs for everyone involved.

We look forward to working with other consent managers to make it easy for the data fiduciaries to manage the consent choices of their data principals.