Privacy & data-subject requests
Under GDPR, you are the controller for your end users’ data and Oclavex is your processor. End users file privacy requests with you; your administrators forward them into Oclavex, which executes them across the platform’s data stores.
There are no end-user privacy endpoints by design — identity verification is yours (you know your customers), so filing is an admin operation.
How a request flows
Section titled “How a request flows”- Your support desk verifies the subject’s identity through your own channel.
- An administrator files the request — portal Compliance → Privacy requests,
or
POST /api/v1/privacy/admin/data-subject-requestswith the subject’s email. - The request starts as Approved (your verification is the approval) and executes asynchronously across the platform. Four kinds are supported: access, portability, rectification and erasure.
- When it finishes it moves to Completed: access and portability requests produce a
downloadable export; rectification applies the corrected values. An erased customer user is
announced as a
User.Deletedwebhook event, without their email, so your CRM and downstream systems can remove their copy.
A request still in progress at the 30-day deadline does not auto-complete — it moves to EscalatedManual, a manual queue where an operator finishes it by hand, so an overdue request is flagged rather than sitting unnoticed.
An unfounded or unverifiable request can be rejected only before execution
starts: POST .../data-subject-requests/{id}/reject with a reason. Filing
starts execution at once, so screen the request before filing it. List and
inspect requests with GET /api/v1/privacy/admin/data-subject-requests (scopes:
privacy.read to view, privacy.write to file and reject).
Automate on the lifecycle
Section titled “Automate on the lifecycle”Subscribe to the webhook event
DataSubjectRequest.Completed to learn when a request has finished, without polling —
filing is your own action, so there is no event for it. The payload names the request
and any failedCategories, and carries no email: you filed the request, so you know
whose it is.
What erasure erases — and keeps
Section titled “What erasure erases — and keeps”Erasure removes or de-identifies the subject’s personal data. A few records are deliberately retained in de-identified form, on documented legal bases:
- Audit records survive, with the user reference replaced by an irreversible pseudonym — the trail stays intact without identifying anyone.
- License and usage records needed for integrity and fraud prevention are likewise pseudonymized rather than dropped.
- Profile data and outbound messages to the subject are deleted outright.
If the person returns and is erased again, earlier pseudonymized records stay unlinkable.
A partially-failed erasure still completes — DataSubjectRequest.Completed lists the
failed categories in failedCategories for follow-up — so downstream systems can tell
an erasure that isn’t fully done.
Processing activities (Art. 30)
Section titled “Processing activities (Art. 30)”The register of processing activities — per data category: the lawful basis, retention period and recipients — is viewable in the portal under Compliance → Processing activities, ready to fold into your own Art. 30 records as the processor’s contribution.