TCF version history
Every TCF privacy experience carries a fingerprint of its TCF contents — the vendors, purposes, and publisher restrictions it presents — called its version hash. When that fingerprint changes, the CMP must re-collect consent from users. TCF version history records each change to that hash — what changed, when, and which action triggered it — so you can audit exactly when and why re-collection was required.
Fides recomputes the hash whenever a TCF experience's configuration changes and records a new entry only when the hash differs from the last one. Each entry captures the previous hash, the new hash, a timestamp, the trigger, and a structured diff. Recording is automatic — nothing to enable beyond TCF itself.
View the history in the Admin UI
- Go to Consent → Experiences.
- Find the experience whose component is TCF overlay, then click History → next to the component tag. This link appears only for TCF overlay experiences.
- The TCF version history page lists every hash change for that experience, newest first.
If no changes have been recorded, the page shows an empty state; entries appear automatically after the first change.
History table columns
| Column | Description |
|---|---|
| Date | When the hash changed. |
| Trigger | The action that caused the change (see Triggers). |
| Changes | Plain-language summary of the diff, e.g. "3 vendors added, 1 purpose changed". Shows "no diff recorded" when no structured diff is available. |
| Hash change | The previous and new hash, shown as previous → current. |
"No diff recorded" appears when Fides can't itemize the change. This happens for the first entry on an experience — there's no earlier version to compare against — and when the hash changes for a reason the diff doesn't track. The most common example is a TCF policy version change: the version hash covers the policy version in addition to the vendors, purposes, and publisher restrictions the diff itemizes, so a policy-version bump alone re-collects consent without a per-item diff.
Click any row to open the Version details drawer, which shows the full timestamp, the trigger, and an itemized diff — e.g. Vendor 755 added or V123 P2: none → consent — so you can see the exact vendor, purpose, and restriction changes behind the transition.
Triggers
The Trigger column names why each change was recorded:
| Trigger | Meaning |
|---|---|
| Config update | The experience configuration was updated — for example, vendors were added or removed. |
| Limited update | A partial update to the experience configuration changed the hash. |
| Served uncached | The experience was served when no cached version hash existed, so Fides computed and recorded the current hash. |
| Compass sync | A scheduled Fides Compass sync updated vendor data. Fides refreshes vendor changes automatically about once per week. |
| Config deleted | A TCF configuration applied to the experience was deleted. |
| Restriction added | A publisher restriction was created. |
| Restriction updated | A publisher restriction was updated. |
| Restriction removed | A publisher restriction was deleted. |
| Unknown | The change was recorded without an identified trigger source. |
For why these changes require re-collecting consent, see Managing TCF.
Read the history from the API
Send a GET request to /api/v1/privacy-experience/tcf-hash-history to return a paginated, reverse-chronological list of hash changes.
| Parameter | Description |
|---|---|
privacy_experience_config_id | Return changes for a single experience config. Omit to return changes across all experiences. |
changed_at_gt | Return only changes after this ISO 8601 timestamp. |
changed_at_lt | Return only changes before this ISO 8601 timestamp. |
page, size | Standard pagination controls. |
The request requires an authorized access token with the privacy experience cache read permission. See Generating OAuth Access Tokens for how to authenticate API requests.