Adobe Tags audit events: tracking who changed what

When you need this

A metric breaks the day after a release and nobody in the room remembers touching Tags - but something did change, because the rule that used to fire silently stopped. Or an agency has publish access to a shared property and the standing question is "what exactly did they change last week." Both situations need a change log the UI doesn't hand you by default.

It also matters for compliance-adjacent work: if a consent-related rule or a data element feeding a regulated field changed, being able to produce who changed it, when, and what the prior state was is the difference between an incident report and a shrug.

How to work with it correctly

1. Authenticate against the Reactor API. Audit events are read through Adobe's Reactor API (the programmatic interface behind Tags), which requires an Adobe Developer Console integration with the appropriate Tags scopes - not your normal UI login session.

GET https://reactor.adobe.io/properties/{PROPERTY_ID}/audit_events
Headers:
  Authorization: Bearer {ACCESS_TOKEN}
  x-api-key: {CLIENT_ID}
  x-gw-ims-org-id: {ORG_ID}
  Accept: application/vnd.api+json

# Response items include: action (create/update/delete), object type + id,
# actor (user email/id), and a timestamp - filter/sort client-side by date.

2. Filter by object type before you filter by date. A busy property generates a lot of noise (data elements get tweaked constantly); scoping the pull to rules or extensions first, then narrowing the window around the incident, finds the relevant change faster than reading a full chronological feed.

3. Cross-reference against publish history, not just the audit log alone. An audit event shows something changed in the Development library; it doesn't by itself prove that change reached Production. Match the audit event's timestamp against the property's Publishing tab to confirm the change was actually part of the build that shipped.

4. Store pulls somewhere durable if this matters to you regularly. The API returns a rolling window, not unlimited history - a property with real change-control requirements should export audit events on a schedule into its own log store rather than relying on Adobe to retain them indefinitely.

How to verify it worked

• The API response returns a 200 with a populated data array, not an empty result - an empty array against a known-active property usually means the scope or property ID in the request is wrong, not that nothing changed.
• A specific object ID you know changed (a rule you personally edited) shows up in the results with the correct actor and timestamp - a quick sanity check before trusting the log for an incident review.
• The timeline you build from audit events matches what the Adobe Experience Platform Debugger shows changed in the live library - if the two disagree, the discrepancy is usually an unpublished Development-library change.

Illustrative, not a measured result: a team investigating a dropped conversion event might use the audit-events endpoint to find the exact rule edit and its author within minutes, instead of manually reviewing every rule in the property.

Reactor API endpoints, scopes, and retention windows change between Adobe releases - verify current request formats against Adobe's own Tags API documentation.

FAQ

Does the Tags UI show a change history anywhere?

Only in a limited way - individual rule and data element revisions show a basic version history in the UI, but there's no single consolidated audit log view across the whole property. The audit-events API is the only way to get a unified, filterable change feed.

Can audit events tell us what the previous value of a setting was?

Partly - audit events confirm that an object changed, who changed it, and when, but they don't always return a full before/after diff of every field. For a complete diff, pair the audit event's timestamp with the object's own revision history in the UI, which does show prior saved versions.