Data redaction

Data redaction is Carriyo's per-customer anonymisation feature for GDPR right-to-erasure (and equivalent privacy regimes). It permanently removes the personal data Carriyo holds for one customer from a specific Order and the Shipments associated with it, while leaving the operational record (order ID, line items, status history, fulfillment events) intact for accounting and audit purposes.

This is different from Data deletion, which covers tenant-wide offboarding. Redaction is a surgical operation on a single order's customer fields; deletion is the lifecycle event when a tenant leaves Carriyo entirely.

Two endpoints

Carriyo exposes redaction at both the Order and the Shipment level. They are independent, one does not call the other.

Endpoint	Scope	Cascade
POST /orders/{reference}/redact	Anonymises the Order itself and every Shipment linked to it through its fulfillment orders.	One Order → many Shipments in a single call.
POST /shipments/{shipment_id}/redact	Anonymises a single Shipment only. Does not touch the parent Order.	None, operates on the one Shipment.

Use the Order endpoint when the data subject's records sit inside Carriyo as an Order, typically end-to-end, External WMS, or Order-passthrough integrations. One call covers the Order plus all of its Shipments.

Use the Shipment endpoint when:

• The Shipment was created directly without an Order in Carriyo (the Shipment-only integration shape, Carriyo handles shipping but the order lives upstream).
• You need to redact a single Shipment without touching its siblings under the same Order.
• The Order has already been redacted and a later-arriving Shipment needs the same treatment.

Neither endpoint requires a body, though the Shipment endpoint optionally accepts a reason string for the audit log.

The Order is identified by order_id (default) or partner_order_reference via the ?key= query parameter, the same as every other order-scoped endpoint. The Shipment is identified by shipment_id.

What gets redacted

On the Order (when calling the Order endpoint)

• customer: name, email, phone, identification fields.
• delivery_address and billing_address: recipient name, contact details, address lines.
• customer_collection_address (when present).

On a Shipment (whether reached via the Order cascade or the Shipment endpoint directly)

• dropoff.contact_name, contact_phone, contact_email.
• dropoff.address1, address2, coords.
• Customer-supplied notes on the shipment.

Untouched on either entity:

• IDs and references: order_id, partner_order_reference, shipment_id, tracking number.
• Status history and fulfillment / tracking events.
• Line items, SKUs, quantities, pricing, weights, dimensions.
• Carrier and operational fields: service level, dates, label references.
• Webhook delivery records (already-fired webhooks are not retroactively scrubbed; see Downstream impact below).
• The pickup side of a Shipment (origin location data is not customer data).

Irreversible

Redaction is destructive and cannot be undone. The original customer values are not retained anywhere in Carriyo after the call returns. There is no "unredact" endpoint and no support escape-hatch, the data is gone.

If you need to fulfill a privacy request and preserve a copy for your own legal hold, take the copy before calling redact.

When to use it

• GDPR Article 17 / right-to-erasure. A customer formally requests removal of their personal data from your records and Carriyo holds (or processed) data covered by that request.
• Equivalent regimes. UK GDPR, CCPA "right to delete", LGPD Article 18, and others all map to the same operation.

For routine privacy hygiene that doesn't rise to a formal erasure request, prefer your standard data retention controls — redaction is the heavy hammer.

Downstream impact

Any system that mirrors customer data from Carriyo will hold a stale, pre-redaction copy of the affected fields after a redact call. Two ways to keep them in sync:

• Re-fetch the Order after redaction. The simplest pattern. The redaction call returns the anonymised Order; downstream systems should consume that response (or the corresponding webhook) and overwrite their cached copy.
• Listen for the ORDER_UPDATE webhook. Redaction fires the standard order-update webhook, so any subscriber that already syncs on ORDER_UPDATE will pick up the change without any special handling. The shipment-side dropoff anonymisation fires the corresponding shipment webhooks for the same reason.

How it fits with other modules

• Data protection: the broader picture: encryption, retention, residency, and tenant-level deletion. Redaction is the per-record companion to those tenant-level controls.
• Compliance: the compliance framework that makes redaction necessary in the first place.
• Orders: the entity the Order endpoint operates on (and the cascade root for linked Shipments).
• Shipping: the entity the Shipment endpoint operates on directly, useful when Carriyo holds the Shipment but no Order.