Designing a Rights-Request Intake API for Access, Correction and Erasure

Sections 11 and 12 give Data Principals rights to access their personal data and to correction or erasure of it, and the obvious first implementation is a support inbox where requests land and someone manually works them. This holds up for a handful of requests a month and falls apart well before it becomes an obvious crisis — requests get missed, response times drift, and there is no structured record of what was actually done for each request, which is exactly the record you would need if a request were later disputed.

An intake API turns rights requests into a tracked, structured workflow instead of an email thread: each request gets a unique identifier, a status, a due date, and an audit trail of every step taken to fulfill it. It does not need to be public-facing initially; even an internal API that a simple form or portal calls is a substantial improvement over an inbox, because it forces the request lifecycle to be modeled explicitly rather than handled ad hoc each time.

Before you can act on an access, correction, or erasure request, you need reasonable confidence the requester is who they claim to be, and this is harder than it sounds once you consider that the verification method itself must not create a new personal data collection problem. Matching the request against an authenticated session where the user is already logged in is the simplest and safest path; step-up verification, such as confirming a value already on file, is the fallback for unauthenticated channels.

Whatever the verification method, it needs to be consistent across request types and logged as part of the request record, because a rights-request workflow that sometimes verifies rigorously and sometimes does not is difficult to defend later. Reject or hold requests that fail verification with a clear, recorded reason, rather than silently ignoring them, which looks materially different in hindsight.

The rights request API itself is comparatively simple; the difficulty is almost always on the fulfillment side, locating every place a given individual's data lives across services, databases, data warehouses, backups, and third-party processors. This is where a maintained personal data inventory pays for itself directly: without one, fulfilling an access or erasure request means someone manually asking every team 'do you have this person's data,' which does not scale and is not reliable.

Design the intake API to fan out fulfillment tasks to each system owner as a tracked sub-task under the parent request, rather than a single person manually chasing every team over chat. Each sub-task should have its own status, so the parent request's overall state is a genuine roll-up of real progress, not a guess.

An access request is complete when the data has been compiled and delivered. A correction request is complete when every system holding the record has been updated and any decisions or communications generated from the stale value have been reconciled if relevant. An erasure request has the added complexity from Section 8(7) of needing to cascade to Data Processors and confirm their completion too, which means the API needs a distinct completion condition for erasure that checks processor acknowledgment, not just internal system state.

Build in a partial-fulfillment status for cases where some systems complete quickly and others, particularly processor-dependent steps, lag behind. A request sitting at 90 percent complete for weeks because one processor integration is slow is a real operational signal worth surfacing, not something to bury inside an aggregate 'in progress' status.

The Rights Request Generator and the Request Handling Toolkit on this site are built to complement this kind of intake system — the former helps individuals frame requests clearly, and the latter gives your team a structured internal process to run against once a request lands.