Skip to main content
The item namespace reads the scanned Item’s own data, and it is the namespace you will use for almost everything. Write it as {{item.field_name}} in a Destination URL, or as item.field_name without braces in a condition. See Field Bindings & URL Templates for the syntax rules and the encoding behavior. The exact set of item.* fields depends on the Collection, because a Collection defines its own fields. The tables below cover what every Collection has plus what a new one starts with.

​
Core fields

Four fields exist on every Item in every Collection, are stored in their own database columns, and cannot be renamed or removed.

​
Standard fields

A new Collection ships with these fields defined. They are ordinary configurable fields, not fixed columns: you can relabel, rename, disable or delete them, and the last four are switched off by default, so they resolve to nothing until you enable them on the Collection. item.item_number and item.item_id are different fields. Item Number is the standard SKU-style field above; Item ID is the core identifier that Links can be generated from. There is no item.number.

​
System fields

These are set by QRtub, not by you, and are read-only.

​
Custom fields

Any field you add to a Collection is readable under its field key, with no extra prefix. A field you created with the label “Inspection Due” and the key inspection_due is {{item.inspection_due}} in a URL and item.inspection_due in a condition. Field keys are lowercase letters, numbers and underscores, so a binding for a custom field is always lowercase. If you are unsure of a key, open the Collection’s Fields tab — the key is shown next to the label. Renaming a custom field does not break existing bindings. QRtub rewrites the Destination URLs, fallback URLs and conditions that used the old key when you save the rename, and Page template bindings are stored against a hidden stable identifier that a rename never touches.

​
Things that catch people out

Field names are case-sensitive. item.Status resolves to nothing. item.status works. Tags cannot go in a URL. item.tags is a list, not a single value, and a binding that resolves to a list makes the whole URL count as unresolved — the Destination is skipped rather than opening with construction,rental pasted into it. Tags work normally in conditions, where you test them with in and size():
A disabled field disappears from a Page. When a Page renders, QRtub passes only the Collection’s enabled fields into the data a binding can read, so turning a field off on the Collection makes {{item.that_field}} resolve to nothing on every Page that used it. Dates are text, not numbers. item.created_at, item.manufactured_date and any date custom field come through as ISO-style strings. You can insert them into a URL, but you cannot do arithmetic on them or compare them against today’s date — see Time Fields Reference for why, and what to do instead.