Skip to content

Privacy & data-subject requests

Under GDPR, you are the controller for your end users’ data and MonetizeIt is your processor. End users file privacy requests with you; your administrators forward them into MonetizeIt, 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.

  1. Your support desk verifies the subject’s identity through your own channel.
  2. An administrator files the request — portal Compliance → Privacy requests, or POST /api/v1/privacy/admin/data-subject-requests with the subject’s email.
  3. The request starts as Approved (your verification is the approval) and executes asynchronously across the platform.
  4. On finish it moves to Completed: access and portability requests produce a downloadable export; erasure requests additionally emit a User.Erased webhook event so your CRM and downstream systems can react.

A request that turns out to be unfounded or unverifiable is rejected before it executes: POST .../data-subject-requests/{id}/reject with a reason. List and inspect requests with GET /api/v1/privacy/admin/data-subject-requests (scopes: privacy.read to view, privacy.write to file and reject).

Subscribe to the webhook events DataSubjectRequest.Filed, .Approved, .Rejected, .Completed and User.Erased to keep your ticketing system in step without polling.

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 pseudonymised rather than dropped.
  • Profile data and outbound messages to the subject are deleted outright.

The same subject can be erased again later without the old records becoming re-identifiable.