> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure CTR redaction

> Strip PII from Amazon Connect Contact Trace Records before they leave your AWS account by setting an allow-list or deny-list through the Operata API.

Configure the Cloud Collector to apply your allow-list or deny-list to every Amazon Connect Contact Trace Record (CTR) before it leaves your AWS account.

## Before you start

* The [Cloud Collector CloudFormation stack](/docs/ctr-installation) deployed against your Amazon Connect instance.
* An Operata API token with admin permissions. See [Authentication](/docs/api-authentication).
* The list of CTR fields you want to allow or deny. The field names follow the [CTR data model](/docs/contact-trace-records).

## Steps

### 1. Read the active config

Confirm what the Cloud Collector is using today before you replace it. A `404` means no config exists and the privacy-first default is in effect — the Cloud Collector ships only the mandatory CTR fields.

```bash theme={null}
curl -u "$OPERATA_GROUP_ID:$OPERATA_API_TOKEN" \
  "https://api.operata.io/v1/config/REDACTION_CONFIG/json"
```

### 2. Decide allow-list or deny-list

One config per Operata account. The two shapes are mutually exclusive.

* Use a deny-list (`BLACKLIST`) to ship the full CTR minus the fields you name. Suits accounts that already vet what Amazon Connect emits.
* Use an allow-list (`WHITELIST`) to ship only the mandatory fields plus the fields you name. Suits accounts under tight data-egress controls.

The mandatory keep-list and field semantics live in [Data redaction](/docs/api-data-redaction).

### 3. Apply the new config

`PUT /v1/config/json` is a full replace, not a patch. Send every field you want active in one body.

```bash theme={null}
curl -X PUT -u "$OPERATA_GROUP_ID:$OPERATA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "REDACTION_CONFIG",
    "value": {
      "type": "BLACKLIST",
      "fields": ["Attributes.CustomerDetails"]
    }
  }' \
  "https://api.operata.io/v1/config/json"
```

A `200 OK` with body `REDACTION_CONFIG updated` confirms the new policy is durable. A `400` with `REDACTION_CONFIG not valid` means the body failed validation — see [Update redaction config](/docs/api-update-redaction-config) for the body schema.

### 4. Wait for propagation

The Cloud Collector caches the active config and refreshes it on a 30-minute interval. Contacts that end inside the propagation window may still ship under the previous policy. For changes that must take effect immediately, stop the EventBridge pipe, wait for the refresh, then restart.

## Result

Place a test contact (see [Send your first observation](/docs/guides-send-first-observation) for the procedure), then read the contact back through the API. On an allow-list, only the mandatory fields plus the fields you named appear. On a deny-list, the named fields are absent from the response payload.

```bash theme={null}
curl -u "$OPERATA_GROUP_ID:$OPERATA_API_TOKEN" \
  "https://api.operata.io/v1/data/calls?fromTime=2026-05-18T00:00:00Z&toTime=2026-05-18T23:59:59Z&size=1"
```

## Related

* [Data redaction](/docs/api-data-redaction) — the reference index for the config schema, mandatory fields, and propagation contract.
* [Update redaction config](/docs/api-update-redaction-config) — every parameter and error code on the `PUT`.
* [Delete redaction config](/docs/api-delete-redaction-config) — remove the config and revert to the privacy-first default.
* [Privacy and redaction](/docs/concepts-privacy-and-redaction) — the model behind allow-list, deny-list, and edge filtering.