Audit Event - Liquid Tag Reference
On this page
The audit_event tag records a custom entry in the audit log from a theme. Use it to capture actions that matter to the business but are not standard StoreConnect events, such as a loyalty tier change or a customer deleting a saved address.
Syntax
```liquid
{% audit_event “loyalty_tier_changed” %}
{% audit_event “loyalty_tier_changed”, message: “Upgraded to gold” %}
{%- assign tier_detail = ‘{“from”:”silver”,”to”:”gold”}’ | deserialize -%} {% audit_event “loyalty_tier_changed”, message: “Upgraded to gold”, detail: tier_detail %} ```
| Property | Value |
|---|---|
| Tag Name | audit_event |
| Type | Simple tag |
| Output | None. The tag renders an empty string |
| POS support | No |
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
| First argument | String | Yes | The name of your event, in quotes. Recorded in Custom Event Name |
message |
String | No | A short human-readable summary, up to 255 characters |
detail |
Object | No | Event-specific detail, stored as JSON in Details. Build it with deserialize |
Building the detail value
Liquid has no object literal, so build detail with the deserialize filter and pass the resulting object:
```liquid
{%- assign deleted_detail = ‘{“nickname”:”Office”}’ | deserialize -%} {% audit_event “address_book_entry_deleted”, message: “Customer deleted a saved address”, detail: deleted_detail %} ```
:::warning Passing a raw JSON string rather than a deserialized object stores it as an escaped string instead of structured detail, and secret filtering cannot apply to it. Secret filtering matches on key names, so it needs real keys to match against. :::
Recorded values
Every entry the tag makes is recorded on the Audit Log object as:
| Field | Value |
|---|---|
| Event Type | custom, always |
| Custom Event Name | Your first argument |
| Category | CUSTOM |
| Severity | NOTICE |
| Channel | web |
| Outcome | success |
| Actor | The logged-in customer, when there is one |
Event Type is always custom, so a theme cannot record an entry that looks like a standard event such as login or payment_succeeded.
Limits
- The store must record the Custom category. Because entries are
NOTICE, they are recorded only when the store’s Audit Log Level isStandardorVerboseandCustomis one of its Audit Log Categories. Categories are all enabled when Audit Log Categories is blank. - Ten entries per request. Further calls in the same request are ignored silently. Do not put this tag inside a loop over products or line items.
- Secrets are stripped by key name. Any key in a structured
detailwhose name containspassword,passwd,secret,token,api_key,apikey,_key,crypt,salt,certificate,card_number,cardnumber,authorization,ssn, orotp, or is exactlypan,pin,cvv, orcvn, is stored as[FILTERED]. A key that names a secret any other way, such associal_security_numberor a barekey, is stored as written. Filtering matches key names, so it cannot redact a secret buried in a plain string. Do not rely on it, and avoid passing sensitive values at all. - Length limits.
messageis capped at 255 characters anddetailat 32768. Longer values are truncated rather than rejected, so adetailover the limit is stored as incomplete JSON. - A failed write never breaks the page. If the entry cannot be recorded, the tag renders nothing and the page continues. An undefined variable passed as
messageordetailstill shows a Liquid error, because it is evaluated before the entry is written.
Example
Record a preference change by placing the tag on the page your marketing preferences form returns to after a successful submit, such as /preferences-saved. The tag runs each time that page renders, so use a page that only a successful submit leads to.
```liquid
{% audit_event “marketing_preferences_changed”, message: “Customer updated marketing preferences” %} ```
The entry appears on the Audit Log list with Event Type custom and Custom Event Name marketing_preferences_changed.
Was this article helpful?
Thanks for your feedback! It helps us improve our docs.