Metafields in Aqua / Liquid
Every owner that supports metafields exposes ametafields drop on its
Aqua/Liquid object. Access follows the standard
{owner}.metafields.{namespace}.{key} pattern, so theme code that reads
metafields stays portable.
For the full data model (types, owners, validations, REST API), see
Metafields Overview.
The basic pattern
{{ … }} triggers toString() on the metafield drop, which renders
type-aware (see render rules below). .value
returns the decoded value (number, array, object, …). .type returns
the type string.
Missing namespaces and missing keys return an empty drop — {{ … }}
prints empty string, {% if … %} is falsy, no exception is thrown.
This makes it safe to reference fields that may not exist on every
resource.
Owners
Render rules per type
{{ metafield }} (without .value) calls a type-aware toString:
Examples
Text and numbers
Rich text (HTML)
Therich_text_field type renders the stored HTML unescaped — perfect
for care instructions, warnings, formatted descriptions:
Boolean conditionals
Lists
Money
Measurements
Color
Date
Reference (file)
JSON
Defensive access
Use{% if %} to guard optional fields — missing keys are falsy:
default:
Across owner types
Same access pattern, every owner:Performance
Metafields are bulk-loaded server-side alongside the parent resource — one query loads the resource, one query loads all its metafields, and both are cached together. There is no per-field network round-trip from Liquid. When a metafield is written via the REST API, the relevant caches are invalidated automatically. The next render sees the new value within ~1 second.See also
- Metafields Overview — types, owners, REST API
- Create / Upsert Metafield — write from your app
- Aqua Filters —
money,date,default, etc.