Skip to main content

Overview

Kibo’s Redaction Services provide a two-phase workflow for processing data subject erasure requests as required by privacy regulations such as:
  • GDPR (General Data Protection Regulation — EU/EEA)
  • CCPA / CPRA (California Consumer Privacy Act / California Privacy Rights Act — US)
  • LGPD (Lei Geral de Proteção de Dados — Brazil)
  • DPDP (Digital Personal Data Protection Act — India)
  • PIPL (Personal Information Protection Law — China)
  • PDPA (Personal Data Protection Act — Thailand, Singapore, and others)
  • LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares — Mexico)
Regardless of the specific regulation, the workflow is the same: identify the data subject’s PII, review the scope, and irreversibly remove it. The two phases are:
  1. Create a draft report — Kibo scans the tenant’s data for all PII associated with the subject and returns a report listing every affected record. No data is modified at this stage.
  2. Execute the redaction — After reviewing the draft, you trigger the irreversible redaction that overwrites or removes the identified PII.
This separation exists to provide an auditable review step before any destructive action is taken. Your compliance team can inspect exactly what will be redacted before committing.

How This Domain Fits Into Kibo

A single data subject’s PII can exist across many parts of the Kibo platform. The redaction engine covers: The two-phase design lets you audit the scope of a deletion request before executing it — important both for regulatory compliance and for avoiding accidental data loss.

Prerequisites

  • Kibo API credentials (client ID and shared secret) with access to the platform/data namespace
  • The customerAccountId (integer) or userId (string) of the data subject whose data must be erased
  • An understanding of any custom attribute FQNs attached to orders, customers, returns, or shipments for your tenant, if you need those included in the redaction

The Two-Phase Workflow

Phase 1 — Create a Redaction Report (Draft)

Endpoint: POST /platform/data/redaction/reportAPI reference This call scans the tenant’s data and returns a draft report. No data is modified.

Request body

Field descriptions:

Example response

The key field to note is status: "Draft". The report has been created and the affected entities have been identified, but nothing has been changed yet.

Phase 2 — Review the Draft Report

Endpoint: GET /platform/data/redaction/report/{reportId}API reference Retrieve the draft report and verify the scope before committing to the redaction.
Review the affectedEntities object carefully:
  • orders.count / orders.ids — the orders that will have PII removed
  • payments.count / payments.ids — payment records linked to those orders
  • checkouts.count / checkouts.ids — any checkout records found
  • returns.count / returns.ids — return records
  • wishlists.count / wishlists.ids — wishlist records
  • shipments.count / shipments.ids — shipment records
  • customerAccountId — the resolved account ID of the subject
Confirm that status is "Draft" before proceeding to execution. A report with status: "Executed" cannot be executed again.

Phase 3 — Execute the Redaction

Endpoint: POST /platform/data/redaction/execute/{reportId}API reference
Execution is irreversible. Once you call this endpoint the identified PII is permanently removed or overwritten. There is no undo. Ensure the draft report has been reviewed and approved before proceeding.
This endpoint has no request body. The reportId in the path identifies which draft to execute.

Example response

After execution, status changes to "Executed", executionCompletedAt is populated, and operationLog contains one entry per operation performed.

Reading the operation log

If any entries have status: "Failed", check errorMessage for details and review errorSummary on the report for a rolled-up description.

Listing and Auditing Reports

Endpoint: GET /platform/data/redaction/reportAPI reference Use this endpoint to retrieve a paginated list of reports — useful for auditing which requests have been fulfilled and which drafts are awaiting execution.

Query parameters

Example request

Example response

Note that the list response returns RedactionReportSummaryResponse objects, which do not include affectedEntities, request, or operationLog. To get those fields, retrieve the individual report by ID.

Field Reference

Key fields on RedactionReportResponse:

Troubleshooting

Empty affectedEntities on a draft report The subject identifier provided (customerAccountId or userId) did not match any records. Verify the ID is correct for your tenant. Note that customerAccountId is a tenant-scoped integer, not a global Kibo user ID. 400 or 422 when creating a report Ensure you are providing at least one of customerAccountId or userId. Providing neither, or providing an attributeFqns array with invalid FQN strings, will result in a validation error. Attempting to execute an already-executed report Once a report has status: "Executed", calling POST /platform/data/redaction/execute/{reportId} again will return an error. Each data subject erasure request requires a new draft report. Partial failures in the operation log If some operationLog entries show status: "Failed", the redaction completed partially. Records that failed were not redacted. Review each failed entry’s errorMessage. You may need to create and execute a new report to retry the affected records, or investigate the underlying data integrity issue before retrying.