Overview of Data Subject Removal API

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Essential knowledge

Changed on:

26 Mar 2026

Overview

The Fluent Commerce platform supports GDPR's Right To Forget in regard to a customer's PII data
Users can submit Data Subject Removal requests to anonymize entities stored in Fluent platform containing a customer's data with the GraphQL API
This documents provides an overview of the Data Subject Removal process and GraphQL capabilities

Key points

Data Subject Removal process
Entities & Events covered by anonymisation
Request Lifecycle & Status Model
GraphQL Requests Examples

Data Subject Removal Process

The Data Subject Removal (DSR) feature introduces a dedicated domain model and execution boundary to ensure that anonymization workloads are fully isolated from Entity API and Event API runtimes.The anonymization workflow is built as an asynchronous, event-driven pipeline that separates request ingestion, orchestration and execution. This architecture enables scalable, fault-tolerant processing of anonymization tasks while preserving the performance and availability of customer-facing APIs.The system defines two core persistent entities:

`DSRRequest` — represents a logical anonymization request initiated by a user
`DSRRequestItem` — represents an individual anonymization task derived from the request payload. It means one item per customer in request payload.

Fluent Commerce provides APIs for customer integrations in order to submit Data Subject Removal requests. The API consists of a mutation to submit `CreateDataSubjectRemovalRequestInput` with multiple `CreateDataSubjectRemovalRequestItemInput` items representing data subjects to anonymize. Once request is submitted it is stored in status `CREATED`, then asynchronously it will be picked up and processed. If request parameters, namely submitted type and value were resolved into a customer user, the status is changed to `PENDING` and processing of anonymization of entities and events is triggered.

Entities data covered by anonymization

Financial transaction
Invoice
Invoice item
Order fulfilment
Fulfilment choice
Customer order
Return order
Billing account
Credit Memo

Events data covered by anonymization

Billing account events
Order events
Return order events

Request Lifecycle & Status Model

Data Subject Removal (DSR) requests require a well-defined lifecycle and status model to ensure reliable execution, traceability, and operational integrity of anonymization workflows.The lifecycle model serves the following purposes:

provides operational visibility for backend monitoring, debugging, and incident investigation
ensures full auditability of anonymization operations, including initiation time, execution progress, and completion outcome
enforces a controlled execution model for asynchronous, distributed processing
supports bulk anonymization requests where a single `DSRRequest` entity may contain multiple `DSRRequestItem` entities derived from batch input

Each `DSRRequest` entity represents a logical anonymization request while individual identifiers within the request are represented as separate `DSRRequestItem` entities and processed independently.

Statuses

The system maintains lifecycle state at both the request level (`dsr_request`) and the item level (`dsr_request_item`).Each `DSRRequestItem` represents an independent anonymization task and progresses through its own lifecycle:

`CREATED` — item has been persisted and is awaiting execution
`PENDING` — the item contains the corresponding `platform_user_id` and is ready to be picked up by a worker.
`RUNNING` — item is actively being processed by worker
`COMPLETED` — anonymization for this identifier is completed successfully
`FAILED` — anonymization for this identifier is terminated due to an unrecoverable error

The lifecycle of the parent `DSRRequest` is derived deterministically from the aggregate state of its associated `DSRRequestItem` records. The status of a `DSRRequest` is computed based on the statuses of all its associated DSRRequestItems using the following rules:

Condition	Resulting DSR Request Status
All items are in CREATED	CREATED
At least one item is PENDING	PENDING
At least one item is RUNNING	RUNNING
All items are COMPLETED	COMPLETED
At least one item is FAILED	FAILED

This aggregation model guarantees that failures at the individual item level are reflected at the request level, ensuring accurate representation of anonymization outcomes.In particular:

a single `FAILED` item causes the entire DSR request to be marked as `FAILED`
the DSR request remains in `PENDING` state while any item is still waiting for processing
the DSR request remains in `RUNNING` state while any item is still in progress
the request is marked `COMPLETED` only when all items complete successfully

This hierarchical status model ensures:

deterministic and consistent lifecycle progression
accurate propagation of execution outcomes
clear visibility into anonymization success or failure
strong auditability and traceability

The request-level status is therefore a reliable indicator of the overall anonymization result.

GraphQL Requests Examples

The following examples, illustrate a sequence of requests between a customer's integration and tge Fluent Commerce platform when submitting and querying Data Subject Removal Requests.

Submitting user by email address

`<ADD GRAPHQL MUTIATION EXAMPLE WITH EMAIL>`

Submitting user by phone number

`<ADD GRAPHQL MUTIATION EXAMPLE WITH PHONE>`

Polling for request status

`<ADD GRAPHQL QUERY EXAMPLE>`

Reading successful anonymization request

`<ADD GRAPHQL QUERY EXAMPLE - success response>`

Handling errors in anonymization request

`<ADD GRAPHQL QUERY EXAMPLE - error response>`