Privacy rights requests

A privacy-rights request is recognised at intake, given the statutory deadline for its regime, and opened as reviewable work with that clock already running. It usually arrives as one sentence inside a longer email, carrying a deadline nobody can see. As a note it has no due date, no owner, and no queue, and the first anyone hears about the deadline is after it has gone. So intake computes the statutory due date and creates the review work in the same call.

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": "412",
    "requestType": "DELETION",
    "regime": "CCPA_CPRA",
    "summary": "Customer requests deletion of personal information.",
    "caseId": 1001,
    "sourceInteractionId": 3001
  }'

{
  "requestId": 7501,
  "status": "RECEIVED",
  "statutoryDueAt": "2027-05-31T23:59:59-07:00",
  "reviewTaskId": 3302,
  "resourceId": 7501
}

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" }
}

A rejection is a first-class outcome carrying the same required outcomeReason, because the obligation is to answer within the deadline rather than to agree — and a platform with no way to record no, and here is why leaves declined requests sitting open and apparently late.

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.

Receiving a request is not deciding it

Intake and fulfillment are separately authorized on purpose. The communications agent records a request the moment it recognises one in an inbound message, which is what starts the clock honestly; deciding it needs the second permission. Joining the two would force a choice between letting everybody grant deletions and letting nobody log a request until a specialist is free.

One message, several regulated matters

A privacy request often arrives alongside other regulated signals. Each keeps its own record and its own deadline, because satisfying one says nothing about the others and a single case marked closed would take the rest with it:

• 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.