Consent and privacy

Kentro Pixel decides per event whether it may be collected, based on the event's consent purpose, the visitor's consent snapshot and the property's consent settings. It also scans every event for sensitive data and handles export, deletion, anonymization and consent withdrawal requests for one person at a time.

In this page

• Purposes
• Property consent settings
• What suppression means
• Consent record
• Sensitive-data quarantine
• Sensitive path patterns
• Form fields and lead details
• Privacy requests
• Limits with external providers

Purposes

Every event has one consent purpose: analytics, marketing or functional. It is fixed per event by its schema (see Events). The envelope's consent snapshot gives a state per purpose: granted, denied or, when missing, unknown. Missing consent never counts as granted unless the property's settings say so.

Property consent settings

settings.consent is set at creation or with PATCH /v1/properties/:id. In Kentro GO, use the property's Settings tab.

privacy_mode: "strict" forces both requirements on and defaultWhenUnknown to denied, whatever the settings say. Settings are merged one level deep: when you change consent, send the whole consent object, because keys you leave out fall back to their defaults.

curl -sS -X PATCH https://apis.kentro.live/pixel/v1/properties/$PROPERTY_ID \
  -H "Authorization: Bearer $KENTRO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "settings": { "consent": { "requireForAnalytics": true, "requireForMarketing": true, "defaultWhenUnknown": "denied", "honorGpc": true }, "sensitivePathPatterns": ["/account", "/patients"] } }'

An unknown marketing state is never treated as granted for exports: anything that needs marketing consent later (ad networks, marketing audiences and exports) still requires an explicit grant in the person's consent record.

What suppression means

A suppressed event is recorded with processing_status: suppressed_consent so that consent coverage can be measured. It is stored minimized: the event name, timestamps, the consent snapshot and a coarse context (referrer domain, device class, bot flag and locale), without properties, identifiers, references, page URL or page title. It never enters sessions, conversions, attribution, audiences or destination deliveries, and it does not use up its event_id.

When the snapshot states a choice (a purpose explicitly granted or denied, or an active GPC signal), the suppressed event also keeps the person keys the consent record is filed under. Kentro records the stated choices in the consent record, then removes those keys from the stored event.

Consent record

Kentro keeps a consent record per property for each person key: the anonymous id (anonymous), the signed-in subject reference (authenticated) and the commerce customer reference (commerce_customer). Audiences and destination deliveries check it at the time of use, on top of the decision taken at ingestion.

• Only explicit choices are recorded: a purpose left unknown is not a choice, so a property default never becomes a decision.
• Choices are ordered by the time Kentro received them; the recorded_at your banner sends is kept as evidence only. A GPC signal stays in force until a snapshot says gpc: false.
• A consent_withdrawal privacy request records every purpose as denied. A later snapshot overrides it only when its choice was recorded after the withdrawal was received.
• At use time, marketing needs an explicit grant (and no GPC signal where the property honors GPC); ad networks need an explicit marketing grant and no GPC signal at all; analytics follows the explicit state, else the property's rule; functional is allowed unless explicitly denied.

Sensitive-data quarantine

Before an event is stored, Kentro scans the string values of properties, the page title, the page path, UTM values, references and the form field values of lead events with four detectors:

• A hit quarantines the event: the status is quarantined with SENSITIVE_PAYLOAD, properties becomes { "quarantined": true }, the page title becomes [redacted], a matching page path is redacted and a matching UTM value or reference removed. Only the detector names are kept, and the event is never processed.
• A payload too large or too deeply nested to scan completely (more than 2,000 strings or 12 levels) is quarantined as SENSITIVE_SCAN_INCOMPLETE.
• Authoritative commerce events from your server are not quarantined: the matching fields are replaced by [redacted] (id-like fields by a stable redacted_ value), the order still counts as revenue, the result carries SENSITIVE_REDACTED, and the event is never forwarded to destinations.

Because page titles are scanned as free text, a page titled "Book an appointment" quarantines every page view on it. settings.privacy.healthVertical (true, false or null; null, the default, means on under strict privacy mode) widens the scan for health businesses: clinical words then count in every string, and the generic health words count too.

Sensitive path patterns

settings.sensitivePathPatterns lists the URL paths that carry personal or sensitive data, for example account, order or patient pages. Matching paths are redacted in page_url, page_path and every URL- or path-valued property. In Kentro GO, set them in the property's Settings tab.

• Patterns start with / (or **/) and are at most 200 characters and 20 segments; a property can have up to 50. Matching is case-insensitive and also tries percent-decoded segments.
• Redaction starts at the last segment of the matched part: /account/orders/1001 becomes /[redacted]/[redacted]/[redacted], and /patient/123/labs/today becomes /patient/123/[redacted]/[redacted].
• Regular expressions are not accepted. A plain expression such as ^/account is converted when it is saved; anything else is refused with 400. A stored value that cannot be converted redacts every path (/*) until it is fixed.

Form fields and lead details

Lead events (marketing.lead_captured and marketing.form_submitted) may carry properties.fields as an object of field values. The event record keeps only the field names (for form_submitted) and the hashed customer.email_sha256 and customer.phone_sha256; the values are scanned and then discarded. Only when settings.lead.rawEmail is true (default false; true for landing pages created by Kentro GO) and the event was accepted, the trimmed and format-checked email, name and phone are added to the person's Pixel record (the newest 20 submissions are kept), where a privacy deletion removes them.

Privacy requests

Privacy requests cover one person across every identifier Kentro Pixel knows. All four routes need pixel:manage. In Kentro GO, the Pixel page's Privacy tab files and follows them.

curl -sS https://apis.kentro.live/pixel/v1/privacy/requests \
  -H "Authorization: Bearer $KENTRO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "delete",
    "subjectKeys": [
      { "type": "email_sha256", "key": "[email protected]" },
      { "type": "anonymous_id", "key": "anon_6f1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e" }
    ]
  }'

email_sha256 and phone_sha256 keys accept a SHA-256 hex digest or a raw email address or phone number; raw values are hashed on arrival (email trimmed and lower-cased; phone reduced to 7 to 15 digits) and discarded. Other keys are 1 to 256 characters. An unusable key answers 400 INVALID_SUBJECT_KEY.

{
  "id": "0192f0c9-4d5e-7f60-8172-8c9d0e1f2a3b",
  "type": "delete",
  "subjectKeys": [
    { "type": "email_sha256", "key": "8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d" },
    { "type": "anonymous_id", "key": "anon_6f1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e" }
  ],
  "status": "received",
  "requestedBy": "7d1f2e3a-4b5c-4d6e-8f90-1a2b3c4d5e6f",
  "verification": { "requestedVia": "pixel-api", "requestedBy": "7d1f2e3a-4b5c-4d6e-8f90-1a2b3c4d5e6f", "requestedAt": "2026-10-09T18:00:00.000Z", "subjectKeyCount": 2, "hashedFromRaw": 1 },
  "result": null,
  "resumable": false,
  "createdAt": "2026-10-09T18:00:00.000Z",
  "completedAt": null,
  "jobId": "0192f0c9-4d5f-7a71-9283-9d0e1f2a3b4c"
}

Requests run asynchronously. Follow one with GET /v1/privacy/requests/:id or list them with GET /v1/privacy/requests?status&type&limit&cursor. Statuses are received, verifying, processing, completed and failed.

• A request covers exactly one person. A device the person shared with someone else is listed in result.sharedDevices for your review, and only the requester's own records on it are touched.
• Hashed email and phone keys also match retained lead records.
• A very large request stops after 50,000 events in one run and is recorded failed with result.partial: true and "resumable": true; Kentro retries it automatically. If it is still failed after the automatic retries, POST /v1/privacy/requests/:id/resume queues it again (202). That route answers 409 NOT_RESUMABLE for a request that is completed, failed for good or still processing, and 409 PRIVACY_JOB_ACTIVE while a run is queued or running.

Limits with external providers

Kentro cannot recall data that a destination already received. When a request is completed, result.destinations lists every destination that is enabled or has delivered before, each with irreversible: true and what to do:

A privacy request does not touch the person's browser. An explicit denial through consentChanged deletes what the SDK stored on that device, and reset forgets everything the SDK stored.