Skip to main content
Configure the Operata Fetcher Service to apply your redaction policy to every Genesys Cloud Conversation it polls, shipping only the surviving payload to Operata.

Before you start

Steps

1. Read the current policy

Inspect what the Fetcher Service is enforcing today before you replace it.
The response carries the full policy across all tiers — MANDATORY, ALLOW, DENY, ENCRYPT, TRANSFORM.

2. Draft your rules

The four customer-configurable tiers are mutually exclusive: any one field appears in at most one tier. Path notation is dot-delimited against the JSON payload, applied at every depth. Each rule is a { "type", "field" } pair. Common drafts:
Rules that target a mandatory field cause the API to reject the policy with 400.

3. Post the policy

POST replaces the active policy in full. Any rule you omit drops out of the policy.
A 200 OK confirms the new policy is durable. A 400 means a rule targeted a mandatory field or the body failed validation.

4. Wait for the cache to refresh

The Fetcher Service caches the policy for 30 minutes. Conversations that end inside that window may still ship under the previous policy. The new policy has no effect on conversations the Fetcher Service already collected — redaction runs at ingest time, not retroactively.

Result

Wait for a real Genesys Cloud conversation to end, then read the resulting contact back through the Operata API. Denied fields are absent from the payload, encrypted fields appear as opaque ciphertext, allowed fields pass through unchanged, and every other field’s value is null.