Privacy rights requests

Record an access, deletion, correction, or portability request with its regime and statutory deadline, route it to compliance review, and close it with a terminal outcome that preserves legal holds.

A privacy-rights request is a deadline-bearing regulated matter. Intake computes the statutory due date and creates the review work; fulfillment records a terminal outcome with its evidence. The two implemented routes exist so neither step can be an unstructured note.

Intake computes the deadline

curl -X POST "$BASE/v1/servicing/privacy-requests" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -d '{
    "customerRef": "123",
    "requestType": "DELETION",
    "regime": "CCPA_CPRA",
    "summary": "Customer requests deletion of personal information.",
    "caseId": 1001,
    "sourceInteractionId": 3001
  }'

{
  "requestId": 7501,
  "status": "RECEIVED",
  "statutoryDueAt": "2026-09-08T23:59:59-07:00",
  "reviewTaskId": 3302,
  "resourceId": 7501
}

Three things happen in that one call, and each is deliberate:

Returned	Why it matters
`statutoryDueAt`	The deadline is computed from `regime` and receipt time, not supplied by the caller. A client cannot set its own due date.
`reviewTaskId`	Compliance review work is created at intake, so the request is on a queue from the moment it exists.
`status: RECEIVED`	Intake is an acknowledgement of receipt, never an implied grant.

requestType and regime are both required: the same request text carries different obligations under different regimes, so the platform will not infer one from the other. caseId and sourceInteractionId are optional but worth supplying — they link the request to the matter and the conversation that raised it, which is what makes the evidence graph traversable later.

Fulfillment is terminal and evidenced

curl -X POST "$BASE/v1/servicing/privacy-requests/7501/fulfill" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -d '{
    "outcome": "FULFILLED",
    "outcomeReason": "Verified export delivered through the approved channel.",
    "evidenceIds": [8801]
  }'

{
  "resourceId": 7501,
  "changes": { "status": "FULFILLED" }
}

The route records fulfillment, rejection, or referral — a rejection is a first-class outcome, not a failure to respond, and it carries the same required outcomeReason. A referral records that another controller or entity owns the response.

Legal holds and evidence survive fulfillment. Completing a deletion request does not remove records a hold, investigation, or retention obligation requires the platform to keep; it records what was done and on what basis, and the surviving records remain governed by their own retention policy.

Permissions

Operation	Permission
Create a request	`CREATE_SERVICING_PRIVACY_REQUEST`
Record a terminal outcome	`FULFILL_SERVICING_PRIVACY_REQUEST`

Intake and fulfillment are separately authorized on purpose. Front-line staff can receive a request without being able to decide it.

A privacy request often arrives alongside other regulated signals, and each keeps its own record and deadline:

a contact or consent change goes through Consent & contact eligibility;
a communication stop goes through Cease communications;
an identity-theft assertion opens its own matter — see Identity theft & disputes.

Listing (GET /v1/servicing/privacy-requests), retrieval (GET /v1/servicing/privacy-requests/{requestId}), intake, and the /fulfill command are all implemented. An open request is also visible through its review task and the owning case.

This guide describes configurable platform controls, not legal advice. Which regimes apply, what each requires, and how a deadline is computed for your entity are decisions for your counsel to configure and approve.

Intake computes the deadline

Fulfillment is terminal and evidenced

Permissions

Related controls